Security Basics Every AI Coder Needs to Know (Before You Ship)

When you ask Claude to connect your app to a database or an email service, it will often write code that looks like this:

// server.js
const { Pool } = require('pg');

const pool = new Pool({
  host: 'db.myapp.com',
  database: 'myapp_production',
  user: 'admin',
  password: 'MySuper$ecretPassword123',  // ← DANGER
  port: 5432
});

const mailgun = require('mailgun-js')({
  apiKey: 'key-abc123def456ghi789jkl012',  // ← DANGER
  domain: 'mg.myapp.com'
});

This code works perfectly. And if you push it to a public GitHub repository, automated bots will find those credentials within minutes. GitHub has bots scanning every public commit for credential patterns. So does every major threat intelligence service. Your database and your Mailgun account will be compromised before you've even finished your coffee.

// server.js
require('dotenv').config();
const { Pool } = require('pg');

const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,  // ← reads from .env
  port: process.env.DB_PORT || 5432
});

const mailgun = require('mailgun-js')({
  apiKey: process.env.MAILGUN_API_KEY,  // ← reads from .env
  domain: process.env.MAILGUN_DOMAIN
});

Your .env file (which stays on your machine or server, never in Git) looks like:

# .env
DB_HOST=db.myapp.com
DB_NAME=myapp_production
DB_USER=admin
DB_PASSWORD=MySuper$ecretPassword123
MAILGUN_API_KEY=key-abc123def456ghi789jkl012
MAILGUN_DOMAIN=mg.myapp.com

Install the dotenv package with npm install dotenv and call require('dotenv').config() at the top of your entry file. Variables are now loaded from .env at runtime — they never touch your source code.

SQL injection has been in the OWASP Top 10 for over two decades. AI still generates it regularly because string-concatenated queries are simple and readable — exactly the kind of pattern that appears in tutorials and examples that AI was trained on.

// routes/admin.js
app.get('/admin/search', async (req, res) => {
  const { email } = req.query;
  
  // Building query with string concatenation — SQL INJECTION RISK
  const query = `SELECT * FROM submissions WHERE email = '${email}'`;
  
  const result = await pool.query(query);
  res.json(result.rows);
});

If someone visits /admin/search?email=' OR '1'='1, the resulting query becomes SELECT * FROM submissions WHERE email = '' OR '1'='1' — which returns every row in the table. A more malicious payload could drop your entire database. The attack can happen through any URL parameter, form field, or header that gets inserted into a SQL string.

// routes/admin.js
app.get('/admin/search', async (req, res) => {
  const { email } = req.query;
  
  // Parameterized query — user input is NEVER executed as SQL
  const query = 'SELECT * FROM submissions WHERE email = $1';
  
  const result = await pool.query(query, [email]);
  res.json(result.rows);
});

The $1 is a placeholder. The database driver sends the SQL structure and the user data as completely separate items to the database engine. The engine treats $1's value as pure data — never as executable SQL. It's impossible to inject SQL through a parameterized query, no matter what the user submits.

Your contact form accepts a message field. Claude's generated handler probably takes that message and stores it directly in the database and sends it in an email. There's no check on what the message actually contains.

app.post('/contact', async (req, res) => {
  const { name, email, message } = req.body;
  
  // Storing raw, unvalidated user input
  await pool.query(
    'INSERT INTO submissions (name, email, message) VALUES ($1, $2, $3)',
    [name, email, message]
  );
  
  res.json({ success: true });
});

Problems here: There's no limit on message length (someone could submit a 10MB message, repeatedly, crashing your server). There's no email format validation (so garbage data gets stored). There's no sanitization of HTML in the message field (which matters if you ever display submissions in a browser — this is how XSS attacks work). And there's nothing preventing someone from submitting this form 10,000 times automatically.

const { body, validationResult } = require('express-validator');

app.post('/contact',
  // Validate before your handler runs
  body('name').trim().isLength({ min: 1, max: 100 }).escape(),
  body('email').isEmail().normalizeEmail(),
  body('message').trim().isLength({ min: 1, max: 2000 }).escape(),
  
  async (req, res) => {
    // Check for validation errors first
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }
    
    const { name, email, message } = req.body;
    
    await pool.query(
      'INSERT INTO submissions (name, email, message) VALUES ($1, $2, $3)',
      [name, email, message]
    );
    
    res.json({ success: true });
  }
);

Install with npm install express-validator. The .escape() call converts HTML characters to entities, preventing XSS. The length limits prevent database spam. The email validator ensures you're storing real email addresses. This is the minimum validation baseline for any public-facing form.

This is the most common catastrophic mistake for vibe coders specifically, because it combines two concepts (environment variables and Git) that AI often teaches separately without connecting the critical safety rule between them.

The scenario: Claude tells you to use a .env file. You follow the instructions, create the file, add your real credentials. Then you initialize a Git repo and push to GitHub. If you didn't add .env to .gitignore before that first git add ., your secrets are now public.

# Terminal — missing the .gitignore step
git init
git add .        # ← This adds .env if .gitignore doesn't exist yet
git commit -m "initial commit"
git push origin main  # ← .env is now on GitHub forever

Even if you delete the file in a later commit, Git history is permanent. Anyone who cloned your repo or looked at your commit history still has those credentials. You must regenerate every secret that was ever exposed.

# .gitignore — create this BEFORE your first git add
.env
.env.local
.env.production
.env.*.local
node_modules/
*.log

# Safe commit sequence
git init
# Create .gitignore first ↑
git add .gitignore
git commit -m "add gitignore"
git add .    # .env is now excluded
git commit -m "initial commit"
git push origin main

CORS (Cross-Origin Resource Sharing) is the browser security feature that controls which domains can make API requests to your server. When you ask Claude to "fix the CORS error" during development, it commonly generates the nuclear option: allow every origin.

const cors = require('cors');

// Allows ANY website to call your API — dangerous in production
app.use(cors());
// Which is equivalent to:
app.use(cors({ origin: '*' }));

In development this is fine — your localhost:3000 front-end needs to talk to localhost:3001 back-end. But in production, Access-Control-Allow-Origin: * means any website in the world can make requests to your API in the context of a logged-in user's browser. This enables cross-site request forgery (CSRF) attacks and allows malicious sites to access your users' data.

const cors = require('cors');

const allowedOrigins = process.env.NODE_ENV === 'production'
  ? ['https://myapp.com', 'https://www.myapp.com']
  : ['http://localhost:3000', 'http://localhost:5173'];

app.use(cors({
  origin: (origin, callback) => {
    // Allow requests with no origin (like curl or Postman)
    if (!origin) return callback(null, true);
    if (allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true  // Required if you use cookies or Authorization headers
}));

This explicitly allowlists only your real domain in production. In development, it allows localhost origins for your front-end dev server. The credentials: true option is needed if your app uses cookies for authentication or sends Authorization headers — and it requires an explicit origin (not *), which is another reason the wildcard breaks real-world auth flows.