Simple Tech Stacks and Securing Your API Keys

When newcomers build web applications with AI, they often meet terms such as “full-stack architecture”, “CORS policies”, and “environment secrets”. Behind the jargon, the basic structure is simple.

An AI assistant can create a first version of the front end and back end, but you still need to decide where private work happens and how secrets are stored.

If you ask an AI tool to call a provider when someone clicks a button, it may put the provider key in browser code unless you give it a clear security rule. Once a key reaches the browser, other people can copy it.

Understanding this boundary helps you keep credentials private.

Demystifying the tech stack

A “tech stack” is simply the collection of software components chosen to build and run an application. Think of it like a house: the foundation holds the private plumbing and electrical wiring, while the rooms and furniture are what guests see and interact with.

In web development, applications are divided into two fundamental halves:

The Front-end (What the user sees)

The front-end is everything delivered to and executed inside the user’s web browser:

• HTML: The structural skeleton (paragraphs, buttons, forms, images).
• CSS / Tailwind: The visual styling (colors, layout grids, spacing, fonts).
• JavaScript: The interactive behavior (opening a menu, updating state, submitting a form).

Modern lightweight frameworks like Astro (which powers this website) can help you build front ends that load quickly on a range of devices.

The Back-end (The private engine)

The back-end is code that runs on a private web server or serverless environment (such as Node.js, Python, or an edge function):

• It processes database queries.
• It verifies passwords and handles sessions.
• It communicates with external services.

The browser talks to your back end. The back end performs sensitive work and returns only the result the browser needs.

The golden rule of API key security

When you build applications that use artificial intelligence, you receive an API key from providers like OpenAI, Anthropic, Google, or DeepSeek.

Treat an API key like a payment card number with no PIN. Anyone who obtains it may be able to make requests that create charges on your account.

The practical rule is simple: Never expose an API key or private secret in front-end code.

Why front-end keys are immediately visible

Anything delivered to a user’s browser—including your HTML, bundled JavaScript, JSX/TSX client components, and CSS—can be inspected by anyone who right-clicks and selects “View Page Source” or opens browser Developer Tools.

If your front-end JavaScript contains:

// DANGEROUS: Anyone can steal this key from their browser!
const apiKey = "sk-proj-123456789abcdef...";

Your key is permanently compromised the moment you publish or build the page.

The 3 essential security rules to prompt your AI models with

Whenever you ask an AI tool to write application code or connect an external service, include clear security rules in the request. They reduce the chance that the tool chooses an unsafe shortcut.

Rule 1: Strict Server-Side Isolation

Rule 1 prompt instruction:
“Never place API keys, private tokens, or secrets inside client-side code, Astro components, React/Vue templates, or public HTML/JS scripts. All external AI calls, third-party API queries, and secret-bearing requests must execute strictly on private server-side backend endpoints (e.g., API routes or serverless handlers), returning only sanitized payloads back to the client.”

When your app needs AI output:

1. The user clicks a button in the browser (e.g., “Summarize Note”).
2. The browser sends the note text to your own private back-end endpoint (e.g., POST /api/summarize).
3. Your back-end server attaches the secret API key from memory and calls the AI provider.
4. The back-end receives the response and sends only the plain text summary back to the user’s browser.

Rule 2: Environment Variable Storage

Rule 2 prompt instruction:
“Store all sensitive API keys and secrets exclusively in a local .env file using standard environment variable conventions. Never hardcode credentials into any source files or templates. Provide a separate .env.example file populated solely with dummy placeholder values so collaborators know which variables are required without exposing real credentials.”

Your project root should look like this:

# .env (PRIVATE - contains real secrets, never shared)
OPENAI_API_KEY=sk-proj-9876543210abcdef...
ANTHROPIC_API_KEY=sk-ant-api03-abcdef...

# .env.example (PUBLIC - committed to git as a reference template)
OPENAI_API_KEY=your_openai_api_key_here
ANTHROPIC_API_KEY=your_anthropic_api_key_here

Your back-end server loads these variables securely into memory at startup (e.g., via process.env.OPENAI_API_KEY or import.meta.env.OPENAI_API_KEY on the server) without exposing them to the client bundle.

Rule 3: Git Exclusion

Rule 3 prompt instruction:
“Ensure .gitignore explicitly excludes all environment files (.env, .env.local, .env.*.local), credential caches, and secret keys before any files are staged or committed. Verify that no private configuration or secret files can ever be tracked by git or pushed to GitHub or public domains.”

Before running your very first git add or git commit, check that your .gitignore file includes:

# Environment secrets and credentials
.env
.env.local
.env.*.local
*.pem
*.key

# Dependencies and build outputs
dist/
.astro/

If a secret is ever committed to Git, treat it as exposed even if you remove it in a later commit. Revoke it and create a replacement in the provider’s dashboard.

---

With these rules in your prompts, you can ask an AI tool to help assemble an application while keeping credentials and billing details out of the browser.