Security Checklist for AI-Coded Web Apps

The Risk

Without security headers, browsers don't enforce basic protections. Attackers can embed your site in an iframe to steal clicks, trick browsers into executing files as the wrong type, or downgrade your HTTPS connection. These headers are free to add and stop entire categories of attacks.

The Solution

Add a few lines to your hosting configuration that tell every browser visiting your site: always use HTTPS, don't guess file types, don't allow framing, and don't leak the full URL when navigating away. These are one-time settings that protect every page on your site automatically.

The Fix

// vercel.json - add to headers array
{
  "source": "/(.*)",
  "headers": [
    { "key": "Strict-Transport-Security",
      "value": "max-age=31536000; includeSubDomains" },
    { "key": "X-Content-Type-Options", "value": "nosniff" },
    { "key": "X-Frame-Options", "value": "SAMEORIGIN" },
    { "key": "Referrer-Policy",
      "value": "strict-origin-when-cross-origin" }
  ]
}

The Risk

Without CSP, any XSS vulnerability can load external scripts, send data to attacker-controlled servers, or embed your page in malicious iframes. CSP is the most powerful browser-side defense - it tells the browser exactly which sources are allowed for scripts, styles, images, and connections.

The Solution

You add a Content Security Policy header that acts like a whitelist for your browser. You tell it: only run scripts from my own domain, only load fonts from Google Fonts, only connect to my API servers, and don't let anyone embed my page in a frame. If anything else tries to load, the browser blocks it automatically.

The Fix

// vercel.json - add alongside other security headers
{ "key": "Content-Security-Policy",
  "value": "default-src 'self'; script-src 'self';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://*.yourdomain.com;
  frame-ancestors 'self'" }

The Risk

Using Access-Control-Allow-Origin: * on your API endpoints means any website on the internet can call your API from a user's browser. An attacker's site can make requests to your feedback endpoint, booking system, or any other API using the victim's browser - and your server will happily respond.

The Solution

Instead of allowing every website to call your API, maintain a list of your own domains that are allowed. When a request comes in, check if the caller's website is on your list. If it is, allow it. If not, reject it. This way only your own frontend can talk to your backend.

The Fix

// Vercel serverless function
const ALLOWED_ORIGINS = [
  'https://yourdomain.com',
  'http://localhost:5173',  // dev only
];

function getCorsOrigin(req) {
  const origin = req.headers.origin;
  if (ALLOWED_ORIGINS.includes(origin)) return origin;
  return ALLOWED_ORIGINS[0]; // safe default
}

res.setHeader('Access-Control-Allow-Origin', getCorsOrigin(req));

The Risk

Without rate limiting, anyone can call your API endpoints thousands of times per second. This burns your serverless function quota, overloads your backend, and can be used to brute-force codes or spam your feedback/email systems. Serverless functions have no built-in rate limiting.

The Solution

Use a fast counter (like Redis) to track how many requests each visitor has made in the last few minutes. If someone exceeds the limit - say 10 requests per hour for a feedback form - reject additional requests with a "slow down" message. Each endpoint can have its own limit based on how sensitive it is.

The Fix

// Using Upstash Redis (@upstash/redis)
import { Redis } from '@upstash/redis';
const redis = new Redis({
  url: process.env.KV_REST_API_URL,
  token: process.env.KV_REST_API_TOKEN
});

const rateKey = \

The Risk

General rate limiting still allows many password guesses per minute. A login endpoint needs a separate pattern: count only failed attempts, lock out after 5 failures, and reset the counter on a successful login. Without this, an attacker can systematically try passwords within your general rate limit.

The Solution

Keep a separate counter just for failed login attempts per visitor. After 5 wrong passwords, lock them out for 15 minutes. When they log in successfully, reset their failure count to zero. This is different from general rate limiting because only failures count, and a correct password clears the slate.

The Fix

const failKey = \

The Risk

In Vite, any environment variable starting with VITE_ gets bundled into your frontend JavaScript - visible to anyone who views source. If you put an API key, database URL, or secret in a VITE_ variable, it's public. This is the most common accidental secret exposure in React apps.

The Solution

Only use the VITE_ prefix for values that are meant to be public (like your login page domain or API URL). Keep all secrets - API keys, database passwords, private tokens - as regular environment variables without the VITE_ prefix. Those stay on the server and never reach the browser.

The Fix

# Safe as VITE_ (these are public anyway):
VITE_AUTH0_DOMAIN=yourapp.auth0.com
VITE_API_BASE_URL=https://api.yourdomain.com

# NEVER use VITE_ prefix for these:
BREVO_API_KEY=xkeysib-...     # server-side only
DATABASE_URL=postgres://...    # server-side only
KV_REST_API_TOKEN=...          # server-side only

The Risk

Outdated npm packages contain known vulnerabilities that attackers actively exploit. For example, older versions of react-router-dom had an XSS vulnerability via open redirects. Running npm audit before every deploy takes 5 seconds and catches these.

The Solution

Run a single command before every deployment that checks all your installed packages against a database of known vulnerabilities. If anything is flagged, update that specific package. It takes 5 seconds and catches issues that would otherwise require a security researcher to find.

The Fix

npm audit                            # check for vulnerabilities
npm install react-router-dom@latest  # fix specific packages

The Risk

Source maps expose your entire unminified source code to anyone using browser DevTools. Console.log statements in production can leak sensitive data like user IDs, API responses, and internal state. Vite disables source maps by default - don't re-enable them.

The Solution

Add a build setting that automatically strips out all console.log and debugger statements when your app is built for production. This removes any accidental data leaks from debug messages. Also make sure source maps are turned off so nobody can read your original source code in the browser.

The Fix

// vite.config.ts - strip debug logs in production
export default defineConfig({
  esbuild: {
    drop: ['debugger'],
    pure: ['console.log', 'console.info',
           'console.debug', 'console.trace']
  }
});

The Risk

If your app embeds other apps in iframes without sandbox restrictions, those embedded apps get full access to your page. They can read cookies, modify the DOM, or navigate your page. Without postMessage origin validation, any page can send messages that your app trusts.

The Solution

When you embed another app inside your page using an iframe, add a sandbox attribute that restricts what it can do - like allowing scripts but blocking access to your cookies or navigation. Also, when receiving messages from embedded apps, always check where the message came from before acting on it.

The Fix

// Restrict iframe capabilities
<iframe
  src="https://embedded-app.com"
  sandbox="allow-same-origin allow-scripts
           allow-popups allow-forms"
  allow="clipboard-read; clipboard-write"
/>

// Always validate postMessage origin
window.addEventListener('message', (e) => {
  if (!ALLOWED_ORIGINS.includes(e.origin)) return;
  // handle message
});

The Risk

If your React app uses URL parameters in fetch() calls or navigation without validation, an attacker can craft URLs with path traversal sequences (../../etc/passwd) or inject arbitrary paths. The browser will send whatever you put in the fetch URL.

The Solution

Before using any value from the URL (like a page slug or ID), check that it only contains safe characters - letters, numbers, and hyphens. If it contains anything unexpected like dots, slashes, or special characters, reject it immediately. This prevents attackers from tricking your app into loading unintended files.

The Fix

const slug = useParams().slug;
// Only allow alphanumeric and hyphens
if (!/^[a-z0-9\\-]+$/i.test(slug)) return <NotFound />;
fetch(\

The Risk

Using dangerouslySetInnerHTML without sanitization is the #1 XSS vector in React apps. If you render HTML from blog posts, API responses, or markdown-to-HTML conversion, an attacker can inject <script> tags, <img onerror=> handlers, or javascript: links that execute in the user's browser.

The Solution

Use a library called DOMPurify to clean any HTML before displaying it. DOMPurify strips out dangerous elements like script tags and event handlers, keeping only safe content like paragraphs, headings, links, and images. You can also specify exactly which HTML tags and attributes are allowed.

The Fix

import DOMPurify from 'dompurify';

// Sanitize before rendering
<div dangerouslySetInnerHTML={{
  __html: DOMPurify.sanitize(htmlContent)
}} />

// Or restrict to specific tags
DOMPurify.sanitize(html, {
  ALLOWED_TAGS: ['p','br','strong','em','a',
                 'ul','ol','li','h1','h2','h3',
                 'code','pre','img'],
  ALLOWED_ATTR: ['href','src','alt','class'],
});

The Risk

Misconfigured Auth0 can lead to session fixation, stale tokens, or users getting stuck in login loops. Common mistakes: not using refresh tokens (sessions expire abruptly), not handling access_denied errors (infinite redirects), and not clearing stale auth state on retry.

The Solution

Configure your Auth0 login to use refresh tokens so sessions don't expire unexpectedly. Store the login state in localStorage so it survives page refreshes. When a user retries login, clear any leftover state first to avoid getting stuck in a loop. Always force a fresh login prompt so users can't accidentally reuse an old session.

The Fix

// Auth0Provider configuration
<Auth0Provider
  domain={import.meta.env.VITE_AUTH0_DOMAIN}
  clientId={import.meta.env.VITE_AUTH0_CLIENT_ID}
  cacheLocation="localstorage"
  useRefreshTokens={true}
>

// Force fresh login
loginWithPopup({ authorizationParams: { prompt: 'login' } });

// On retry - clear stale state
localStorage.removeItem('auth0...');
sessionStorage.clear();

The Risk

If your Vercel serverless function accepts a JWT token but doesn't validate it, anyone can forge a token and access protected endpoints. The token must be verified against Auth0's public keys, with issuer and audience checked. Without this, authentication is just theater.

The Solution

When your serverless function receives a login token, verify it against Auth0's public keys to confirm it's genuine. Also check that the token was issued by your Auth0 account (issuer) and intended for your app (audience). If any check fails, reject the request. This ensures nobody can create a fake token to access your protected endpoints.

The Fix

import { jwtVerify, createRemoteJWKSet } from 'jose';

const JWKS = createRemoteJWKSet(
  new URL(\

The Risk

Console.log statements in serverless functions persist in Vercel's log dashboard. If you log email addresses, full request bodies, or API response data, that personal information sits in plain text in your hosting provider's logs - accessible to anyone with dashboard access and potentially subpoenaed or leaked.

The Solution

Only log operational information like which endpoint was called, the HTTP method, status code, and how long it took. Never log personal data like email addresses, phone numbers, or full request bodies. If you add debug logging temporarily during development, remove it before deploying to production.

The Fix

// WRONG - leaks PII
console.log('User:', user.email, 'Body:', JSON.stringify(req.body));

// RIGHT - log only operational data
console.log('Request received:', {
  endpoint: req.url,
  method: req.method,
  status: 200,
  ms: Date.now() - start
});

The Risk

Cookies without proper attributes are vulnerable to theft and misuse. Without HttpOnly, any XSS can steal the cookie via JavaScript. Without Secure, the cookie is sent over plain HTTP. Without SameSite, the cookie is sent on cross-site requests (CSRF). Never store auth tokens in localStorage - any XSS can read them.

The Solution

When setting a cookie, add three protective flags: HttpOnly (JavaScript cannot read it), Secure (only sent over HTTPS), and SameSite (not sent when requests come from other websites). Also set an expiry time so the cookie doesn't last forever. Never store login tokens in localStorage - cookies with these flags are much safer.

The Fix

res.setHeader('Set-Cookie', [
  \

The Risk

After migrating to a serverless proxy architecture, leftover backend URLs in your frontend code reveal your infrastructure. Even unused URLs are visible in DevTools or bundled JavaScript. Attackers use this to map your endpoints, probe for vulnerabilities, and replay requests with captured headers.

The Solution

After any architecture change (like switching from direct API calls to a serverless proxy), search your frontend code for old backend URLs and remove them. Your frontend should only reference its own domain - the serverless proxy handles forwarding to the actual backend. Also check for old config files, unused imports, and commented-out fetch calls.

The Fix

// WRONG - exposes backend infrastructure
const API_URL = "https://api.mybackend.coolify.app/query";

// RIGHT - calls own domain, proxy forwards
const API_URL = "/api/query";

// After architecture changes, search for leaked URLs:
// grep -r "coolify\\|hetzner\\|backend" src/

The Risk

Loading JavaScript, WASM binaries, or CSS from external CDNs (sql.js.org, cdnjs, unpkg) means a compromised CDN serves malicious code to all your users. The code executes in your domain's security context with full access to cookies, localStorage, and the DOM. This is a supply chain attack that bypasses all your other security - CSP allows the CDN domain, so the malicious script runs unchallenged.

The Solution

Copy critical assets (WASM binaries, JS libraries, fonts) to your own public/ folder and reference them locally. This eliminates the external dependency entirely - a CDN compromise cannot affect you. If self-hosting isn't practical (large files, frequent updates), use Subresource Integrity (SRI) hashes on the script/link tag. SRI tells the browser: only execute this file if its hash matches what I expect. Any tampering causes the browser to reject it.

The Fix

// WRONG - external CDN dependency
<script src="https://cdn.example.com/sql-wasm.js"></script>

// RIGHT - self-hosted copy
// 1. Download: curl -o public/sql-wasm.js https://cdn.example.com/sql-wasm.js
// 2. Reference locally:
<script src="/sql-wasm.js"></script>

// ALTERNATIVE - SRI hash (if self-hosting isn't practical)
<script src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
  crossorigin="anonymous"></script>

// Generate SRI hash:
// cat file.js | openssl dgst -sha384 -binary | openssl base64 -A

The Risk

Setting server.host = true in vite.config.ts (or using --host flag) binds the dev server to 0.0.0.0, exposing it to everyone on your network. Combined with dev auth stubs that bypass login (always return authenticated), anyone on the same WiFi - coffee shops, hotel networks, coworking spaces - can access your app including admin panels.

The Solution

Only use host: true when you actively need to test on a mobile device on your local network. Remove it when you're done. If your dev environment stubs out authentication (common for faster development), the combination of network exposure + no auth means your app is wide open to anyone nearby. Default to host: false (localhost only) which is safe even on shared networks.

The Fix

// vite.config.ts
export default defineConfig({
  server: {
    // host: true,  // ONLY enable for mobile testing
    host: false,    // default - localhost only (safe)
  }
});

// If you MUST use host: true on shared networks:
// 1. Don't stub auth in dev (use real Auth0 dev tenant)
// 2. Or add a simple dev password middleware
// 3. Disable when done - don't leave it as default

The Risk

When your frontend calls a backend directly (fetch("https://api.mybackend.com/query")), you expose your backend URL to anyone who opens DevTools. Attackers can bypass your frontend entirely - calling your backend directly, replaying requests, probing for vulnerabilities, and brute-forcing endpoints. Any API key or secret needed for that call must be in the frontend code (or absent), and you have no server-side layer to add authentication, rate limiting, input validation, or logging before the request reaches your backend.

The Solution

Route all frontend API calls through serverless functions on your own domain (e.g., Vercel API routes at /api/query). The frontend only ever calls its own domain. The serverless function receives the request, adds the real API key from environment variables, validates input, applies rate limiting (see 1.4), and forwards to the actual backend. The backend URL and API key never reach the browser. This gives you a server-side security layer (auth, rate limiting, input validation, logging, error sanitization) without running your own server. This pattern works for calling your own backends AND third-party APIs - the serverless function can call any external API server-side, adding your API keys and handling auth without exposing anything to the browser. It also solves CORS issues: many third-party APIs don't set CORS headers, so browsers block direct calls from frontend JavaScript. Since serverless functions run server-side, there are no CORS restrictions - the function calls the API freely and returns the result to your frontend on your own domain. Vercel free tier allows up to 300 seconds (5 minutes) per function invocation, which covers most API calls. For operations that exceed this - large file uploads, heavy database imports, long-running data processing - use one-time tokens or signed URLs (see 10.6): the serverless function issues a short-lived token, and the frontend uses it to call the backend directly for that single operation.

The Fix

// WRONG - frontend calls backend directly
const resp = await fetch("https://api.mybackend.com/query", {
  headers: { "X-API-Key": "sk-secret-123" }  // exposed in browser
});

// RIGHT - frontend calls own domain
const resp = await fetch("/api/query", {
  method: "POST",
  body: JSON.stringify({ sql: query })
});

// api/query.ts (Vercel serverless function)
import { Redis } from '@upstash/redis';
const redis = new Redis({ url: process.env.UPSTASH_URL, token: process.env.UPSTASH_TOKEN });

export default async function handler(req, res) {
  // 1. Rate limit (see item 1.4)
  const ip = req.headers['x-forwarded-for']?.split(',')[0] || 'unknown';
  const count = await redis.incr(\

The Risk

ADDITIONAL HARDENING - This is an extra layer of protection beyond what most apps implement. Standard rate limiting (items 1.4, 5.2) and authentication (section 9) already provide solid security for most use cases. Turnstile adds value specifically for high-security apps, admin dashboards, or apps where you want to make absolutely sure no automated tool can interact with your sensitive endpoints. If your app already has rate limiting + authentication and you're not dealing with targeted attacks, you can skip this. Your login page, access code form, or any sensitive endpoint can be hit directly by scripts - someone writes a Python script or uses curl to send thousands of POST requests to your API, trying different passwords or access codes. They never open a browser, never see your UI. Your rate limiting helps, but a clever attacker can slow down their requests to stay under the limit and still brute-force their way in over time. Browser-based protections like Cloudflare's Browser Integrity Check don't help here because the attacker isn't using a browser at all.

The Solution

Add Cloudflare Turnstile to your sensitive forms. Turnstile is an invisible captcha - your users never see a puzzle, never click "I'm not a robot", nothing changes in their experience. Behind the scenes, when your page loads, Cloudflare's script silently checks if the visitor is using a real browser (it looks at JavaScript execution, browser APIs, mouse behavior, and dozens of other signals). If it's a real browser, it generates a one-time cryptographic token. Your frontend sends this token along with the form data. Your server then calls Cloudflare's verification API to confirm the token is real before processing anything. The key thing to understand: this is completely invisible to real users. They fill in the form and click submit - same as before. But a script running curl or Python requests can't generate a valid Turnstile token because it's not a real browser. So the server rejects the request before it even looks at the password or access code. The attacker gets "Bot verification failed" and your actual security logic (code checking, IP blocking) is never reached.

The Fix

// 1. Add Turnstile script to your HTML <head>
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js?render=explicit"
  async defer></script>

// 2. Create a Turnstile widget via Cloudflare API or dashboard
//    Mode: "invisible" (no UI shown to users)
//    Domains: your production domain + localhost for testing
//    You get back: a Site Key (public) and Secret Key (private)

// 3. Frontend - render invisible widget + send token with form
const widgetId = window.turnstile.render(container, {
  sitekey: 'YOUR_SITE_KEY',
  callback: (token) => { turnstileToken = token; },
  size: 'invisible',
});

// Include token when submitting the form
fetch('/api/your-endpoint', {
  method: 'POST',
  body: JSON.stringify({
    code: accessCode,
    turnstileToken: turnstileToken  // <-- add this
  })
});

// 4. Server - verify token with Cloudflare BEFORE processing
const resp = await fetch(
  'https://challenges.cloudflare.com/turnstile/v0/siteverify',
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      secret: process.env.TURNSTILE_SECRET_KEY,
      response: turnstileToken,
      remoteip: clientIp,
    })
  }
);
const data = await resp.json();
if (!data.success) {
  return res.status(403).json({ error: 'Bot verification failed' });
}
// Only NOW check the actual password/code/form data

The Risk

ADDITIONAL HARDENING - This goes beyond standard security practices. Most apps handle failed logins with temporary lockouts (item 1.5) and rely on Cloudflare WAF for IP-level blocking (item 5.2). Application-level permanent blocking is useful when you want zero tolerance for unauthorized access attempts - typically for private admin tools, internal dashboards, or single-user systems where any wrong attempt is suspicious by definition. For consumer-facing apps with thousands of users who might genuinely mistype their password, this would be too aggressive. Cloudflare's WAF rate limiting (item 5.2) blocks IPs that send too many requests in a short window - but the block is temporary (typically 10 seconds to 10 minutes). fail2ban (item 8.2) works at the SSH level, not at the application level. Neither of these can permanently block an IP based on application-specific logic, like "this person entered the wrong access code" or "this account failed login 5 times." You need a way to make blocking decisions inside your application code and have those blocks persist across deploys and server restarts.

The Solution

Use a fast key-value store like Upstash Redis to maintain a blocklist of IP addresses. When something suspicious happens - a wrong access code, too many failed logins, a detected attack pattern - write the IP to Redis with a key like "blocked:{ip}". On every page load, check Redis first: if the IP is blocked, show a "you're blocked" screen immediately without even rendering the login form. This all happens in milliseconds because Redis is fast. The blocking can be permanent (stays until an admin removes it) or time-limited (set a Redis expiry of 24 hours, 7 days, etc.). You decide based on your use case. For a private admin tool, permanent blocking on the first wrong attempt makes sense - any wrong guess is suspicious by definition. For a consumer app, you'd want temporary blocks after multiple failures (see item 1.5). The key difference from Cloudflare or fail2ban: this runs inside your application logic, so you can block based on business rules, not just request volume.

The Fix

// Redis setup (Upstash - works in serverless)
import { Redis } from '@upstash/redis';
const redis = new Redis({
  url: process.env.KV_REST_API_URL,
  token: process.env.KV_REST_API_TOKEN,
});

const BLOCKED_KEY = (ip) => \

The Risk

ADDITIONAL HARDENING - This matters specifically for apps hosted on Vercel behind Cloudflare. If your app isn't on Vercel, or isn't behind Cloudflare, you can skip this. Every app deployed on Vercel gets a public .vercel.app URL in addition to your custom domain. For example, if your custom domain is myapp.com (which goes through Cloudflare), Vercel also creates something like myapp-abc123-yourteam.vercel.app. This second URL goes directly to Vercel, completely bypassing Cloudflare. That means all the Cloudflare protections you set up - WAF rate limiting (item 5.2), Browser Integrity Check (item 5.3), Bot Fight Mode, security level challenges - none of them apply when someone uses the .vercel.app URL. They're talking directly to your server with no bouncer at the door. Anyone can discover this URL. It appears in your Vercel dashboard, in deployment logs, and can sometimes be found through DNS enumeration or by guessing the pattern (project-name.vercel.app). Once they have it, they can hit your API endpoints directly, bypassing your entire Cloudflare defense layer.

The Solution

Enable Standard Protection in your Vercel project settings. This is available on ALL plans, including Hobby (free). It blocks all .vercel.app URLs at Vercel's infrastructure level - visitors hitting the .vercel.app URL get redirected to Vercel's auth page (307), and only your custom domain remains publicly accessible. No code changes needed, no workarounds, no spoofing possible. To enable: Vercel Dashboard > Your Project > Settings > Deployment Protection > select "Standard Protection". That's it. One toggle, problem solved. After enabling, .vercel.app URLs return 307 (redirect to Vercel auth). Your custom domain (e.g., myapp.com via Cloudflare) continues to work normally. All your Cloudflare protections (WAF, rate limiting, bot protection) remain in the path since traffic goes through your custom domain.

The Fix

// Enable Standard Protection:
// Vercel Dashboard > Project > Settings > Deployment Protection
// Select "Standard Protection"
//
// Before: .vercel.app URLs → 200 (bypasses Cloudflare entirely)
// After:  .vercel.app URLs → 307 (redirected to Vercel auth page)
//         Custom domain    → works normally through Cloudflare
//
// This is free on all plans including Hobby.
// No code changes needed - it's an infrastructure-level block.

The Risk

ADDITIONAL HARDENING - Discovered during penetration testing. This applies to any Single Page Application (React, Vue, Angular) hosted on Vercel, Netlify, or similar platforms. SPAs use a catch-all rewrite rule that sends every URL to index.html - that is how client-side routing works. The problem is that this applies to ALL paths, including paths that automated scanners and attackers love to probe: /.env (looking for your secrets file), /.git/config (looking for your git repo), /wp-admin (looking for WordPress admin panels), /phpmyadmin, /xmlrpc.php, and so on. None of your actual files are exposed - the server just returns your app's HTML page with a 200 OK status. But from the scanner's perspective, it sees 200 OK and thinks it found something. This creates noise in security reports and makes your app look like it might be running WordPress or has exposed secrets, when it doesn't. More importantly, a human attacker probing your site sees 200 OK responses everywhere, which encourages them to dig deeper rather than move on.

The Solution

Add explicit redirect rules that return 404 (Not Found) or 403 (Forbidden) for known-bad paths BEFORE the SPA catch-all rule kicks in. The key insight is that redirects in vercel.json (or _redirects on Netlify) are evaluated before rewrites, so you can intercept these scanner paths first. You don't need to block every possible bad path - just the most commonly probed ones. The usual suspects are: /.env and variants, /.git/*, /wp-admin, /wp-login.php, /wp-content, /wp-includes, /xmlrpc.php, /phpmyadmin, and /administrator. Bonus: if you have Cloudflare in front, its WAF may catch some of these first (like /wp-admin returning 403 automatically). The vercel.json rules act as a second layer for paths Cloudflare doesn't catch.

The Fix

// vercel.json - add these BEFORE the SPA catch-all rewrite
// Redirects are evaluated before rewrites, so these take priority
{
  "redirects": [
    { "source": "/.env:path(.*)", "destination": "/", "statusCode": 404 },
    { "source": "/.git/:path(.*)", "destination": "/", "statusCode": 404 },
    { "source": "/wp-admin/:path(.*)", "destination": "/", "statusCode": 404 },
    { "source": "/wp-login.php", "destination": "/", "statusCode": 404 },
    { "source": "/wp-content/:path(.*)", "destination": "/", "statusCode": 404 },
    { "source": "/wp-includes/:path(.*)", "destination": "/", "statusCode": 404 },
    { "source": "/xmlrpc.php", "destination": "/", "statusCode": 404 },
    { "source": "/phpmyadmin/:path(.*)", "destination": "/", "statusCode": 404 },
    { "source": "/administrator/:path(.*)", "destination": "/", "statusCode": 404 }
  ],
  "rewrites": [
    { "source": "/api/(.*)", "destination": "/api/$1" },
    { "source": "/((?!api/).*)", "destination": "/index.html" }
  ]
}

// For Netlify, use _redirects file instead:
// /.env*    /  404
// /.git/*   /  404
// /wp-*     /  404
// /* /index.html 200

// WHAT THIS LOOKS LIKE IN PRACTICE:
// Before: GET /.env → 200 (index.html) - scanner thinks it found secrets
// After:  GET /.env → 404 - scanner moves on, nothing to see
// Before: GET /.git/config → 200 - scanner thinks repo is exposed
// After:  GET /.git/config → 404 - correctly signals "not here"
// Normal SPA routes still work: GET /dashboard → 200 (index.html)

The Risk

Serverless functions on Vercel (and similar platforms) terminate immediately after the response is sent. Any "fire-and-forget" work - logging to an external service, sending analytics, writing audit trails - that runs as an unawaited Promise will be killed mid-flight when the function exits. The platform doesn't wait for background Promises to resolve. Real-world impact: during a security audit, centralized logging was found to be dropping 83% of log entries. The serverless function sent the response to the client, then tried to POST the log event to an external logging service - but the function was killed before that fetch() completed. Out of 6 test requests, only 1 was actually logged. This created a massive security blind spot: attacks, errors, and access patterns were invisible because the logs never arrived. This is particularly dangerous for security-critical logging (access attempts, blocked IPs, auth failures) where missing logs means missing evidence of an ongoing attack.

The Solution

Use the waitUntil() function from @vercel/functions to tell the platform: "I've sent the response, but keep the function alive until this Promise resolves." The function continues running in the background until the logging fetch() completes, then shuts down. This is the official Vercel mechanism for background work after response. The pattern: instead of just calling fetch() and hoping it completes, wrap it in waitUntil(). The function sends the response immediately (no latency impact for the user) but stays alive long enough for the background work to finish. After deploying this fix, the same 6-request test showed 100% log capture - all 6 entries appeared in the database. The fix is a single function call wrapping existing code.

The Fix

// WRONG - fire-and-forget drops ~83% of logs
function logEvent(data) {
  // This Promise is NOT awaited - function may exit before it resolves
  fetch('https://logger.example.com/log', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(data)
  }).catch(() => {});
}

export default async function handler(req, res) {
  logEvent({ endpoint: '/api/data', status: 200 });
  return res.json({ data: 'response' });
  // Function exits HERE - logEvent fetch is killed mid-flight
}

// RIGHT - waitUntil keeps function alive for background work
import { waitUntil } from '@vercel/functions';

function logEvent(data) {
  const logPromise = fetch('https://logger.example.com/log', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(data)
  }).catch(() => {});

  // Tell Vercel: keep function alive until this resolves
  waitUntil(logPromise);
}

export default async function handler(req, res) {
  logEvent({ endpoint: '/api/data', status: 200 });
  return res.json({ data: 'response' });
  // Function sends response but stays alive for logPromise
}

// RESULT: 83% drop rate → 0% drop rate (100% log capture)

The Risk

In a typical serverless architecture, each API endpoint has its own URL (/api/dashboard, /api/aws-costs, /api/duckdb). These URLs are visible in the frontend JavaScript bundle - anyone can open DevTools, read the minified JS, and build a complete map of your API surface. Even with authentication, exposed endpoint names reveal what services you use, what infrastructure you run, and which endpoints to probe for vulnerabilities. For portfolio or showcase apps published on social media, this is especially problematic - people WILL inspect the bundle.

The Solution

Route all API calls through a single POST endpoint (like /api/rpc) using numeric action codes. The frontend sends { a: 2, p: { type: "status" } } instead of GET /api/aws-costs?type=status. The server-side mapping from numbers to handler functions never reaches the browser. Move handler files to a directory that the hosting platform ignores (Vercel skips underscore-prefixed directories like api/_h/). After migration, delete the old endpoint files - they remain reachable even if no frontend code calls them. The result: anyone inspecting the bundle sees only /api/rpc and a set of meaningless numbers. They can't tell what action 2 does without access to the server code.

The Fix

// Frontend: rpc helper (only this file knows the URL)
const RPC_URL = '/api/rpc';

export async function rpc(token, action, params, body, method) {
  return fetch(RPC_URL, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: \

The Risk

Single Page Applications render entirely in JavaScript. Bots, scrapers, and users with JavaScript disabled see a blank page. Search engines may index nothing. Security scanners may report the site as empty or broken, triggering false alarms.

The Solution

Add a <noscript> block in your index.html that displays key information about the site - what it is, what it does, and a link to any static/server-rendered version. This gives bots and no-JS users something meaningful instead of a blank page.

The Fix

<!-- index.html - inside <body>, after the root div -->
<noscript>
  <div style="padding: 2rem; font-family: sans-serif;">
    <h1>My App - Description</h1>
    <p>This application requires JavaScript to run.</p>
    <p>Key features: ...</p>
    <p>Contact: [email protected]</p>
  </div>
</noscript>

The Risk

Per-IP rate limiting stops a single attacker but not a distributed attack. If 100 different IPs each send 10 submissions, they all stay under per-IP limits while flooding your system with 1,000 entries. Feedback forms, email endpoints, and file upload APIs are especially vulnerable.

The Solution

Add a global daily counter (across all IPs) for sensitive submission endpoints. When the total exceeds a threshold (e.g., 200 submissions per day), reject further requests and send an alert email to the site owner. This catches distributed attacks that per-IP limits miss.

The Fix

// Serverless function - Upstash Redis global counter
const globalKey = \

The Risk

When user-supplied content (feedback form text, names, URLs) is inserted directly into an HTML email template, an attacker can inject HTML or JavaScript. If the recipient's email client renders HTML, this can lead to phishing links, invisible tracking pixels, or layout manipulation.

The Solution

Escape all user-supplied content before inserting it into HTML email templates. Replace &, <, >, and " with their HTML entity equivalents. This is a simple string transformation that prevents any HTML injection.

The Fix

// Simple HTML entity escaping function
function escHtml(str) {
  return str
    .replace(/&/g, '&')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;');
}

// Usage in email template
const emailBody = \

The Risk

Using allow_origins=["*"] with allow_credentials=True in FastAPI is especially dangerous - it lets any website make authenticated requests to your API using a visitor's cookies. The real question is: does your API use cookies or header-based auth? This determines whether wildcard origins are safe or dangerous.

The Solution

If your API uses header-based auth (X-API-Key or Bearer token) and never reads cookies, allow_origins=["*"] with allow_credentials=False is safe - the auth header is what protects it, not the origin. This is the practical standard for backends with 30+ frontends. If your API uses cookies for auth, you MUST use an explicit origin allowlist. The key rule: allow_credentials=True + wildcard origins is always dangerous.

The Fix

# PATTERN 1: Header-based auth (X-API-Key / Bearer)
# Wildcard is SAFE here - auth header is the real security
app.add_middleware(CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=False,
    allow_methods=["*"],
    allow_headers=["Content-Type", "Authorization", "X-API-Key"],
)

# PATTERN 2: Cookie-based auth (sessions, JWTs in cookies)
# MUST use explicit origin list - cookies are sent automatically
origins = os.getenv("CORS_ORIGINS", "").split(",")
origins = [o.strip() for o in origins if o.strip()]
app.add_middleware(CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,  # sends cookies
    allow_methods=["*"],
    allow_headers=["Content-Type", "Authorization"],
)

The Risk

Without rate limiting, a single attacker can exhaust your server's CPU, memory, and database connections by sending thousands of requests. This is especially critical for endpoints that run SQL queries or call external APIs - each request consumes real resources.

The Solution

Use a rate limiting library (SlowAPI for FastAPI) that tracks requests per IP address. Set a limit for each endpoint - for example, 30 requests per minute for a data query API. When someone exceeds the limit, they get a "too many requests" response and have to wait.

The Fix

from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.errors import RateLimitExceeded

RATE_LIMIT = os.getenv("RATE_LIMIT", "30/minute")

# Use get_client_ip (item 2.8), NOT get_remote_address
# get_remote_address reads proxy IP behind Cloudflare
limiter = Limiter(key_func=get_client_ip)

# CRITICAL: without this, SlowAPI returns an HTML error page
# instead of a JSON 429 response
app.state.limiter = limiter
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

@app.get("/api/endpoint")
@limiter.limit(RATE_LIMIT)
async def endpoint(request: Request):  # request param is REQUIRED
    ...

The Risk

Rate limiting caps requests per minute, but an attacker can still send 30 simultaneous requests that all start executing at once. Each might run a heavy SQL query or allocate memory. Without concurrency limits, a burst of parallel requests can crash your server even within rate limits.

The Solution

Set a cap on how many requests from the same IP address can be processing at the same time - for example, 4 concurrent requests per visitor and 10 across all visitors. If someone already has 4 queries running, their 5th request waits or gets rejected. This prevents one person from hogging all your server's resources at once.

The Fix

MAX_PER_IP = int(os.getenv("MAX_CONCURRENT_PER_IP", "4"))
MAX_GLOBAL = int(os.getenv("MAX_CONCURRENT_GLOBAL", "10"))

# Critical: use asyncio.shield() on release
# Without shield, if the ASGI middleware cancels
# the request, the counter never decrements (leaks)
async def release_concurrency(ip):
    try:
        await asyncio.shield(_do_release(ip))
    except asyncio.CancelledError:
        pass  # shield caught it - counter is safe

The Risk

If your API accepts SQL queries from users (text-to-SQL, data exploration tools), a single malicious query can drop tables, read password hashes, or generate billions of rows to crash your database. Row limits alone don't protect you - CROSS JOIN creates trillion-row intermediate results before LIMIT applies, REPEAT() generates single-cell 95MB responses, and aggregate functions like STRING_AGG collapse 1M rows into one row bypassing LIMIT entirely. This requires a multi-layer defense - no single check is sufficient.

The Solution

Apply multiple layers of checks before running any user-submitted SQL. First, only allow queries that start with SELECT or similar read-only commands. Then block dangerous keywords like DELETE, DROP, or ALTER. Block resource exhaustion functions - CROSS JOIN (CPU bomb via cartesian products), REPEAT (bandwidth bomb via inflated strings), MD5/SHA256/REGEXP_REPLACE (CPU bombs on computed large strings). Add a SQL parser (sqlglot) for structural validation that catches attacks regex cannot see - CTE alias bypass, implicit cartesian products, nested blocked functions. Block data-generating functions, strip out SQL comments (used to bypass filters), hide system tables, and enforce a row limit. No single check is enough - you need all of them together.

The Fix

# Apply ALL of these layers (regex + parser):
1. Prefix allowlist: SELECT, SHOW, DESCRIBE, EXPLAIN, WITH
2. Keyword blocklist: INSERT, UPDATE, DELETE, DROP, ALTER,
   CREATE, TRUNCATE, EXEC, COPY, GRANT, REVOKE, SET...
3. Block GENERATE_SERIES, RANGE, UNNEST (billion-row attacks)
4. Block CROSS JOIN, REPEAT, LPAD, RPAD, REGEXP_REPLACE, MD5, SHA256
   (CPU and bandwidth bombs - small output, massive compute)
5. SQL parser structural check (see item 2.4b for details)
   (catches CTE bypass, aliased self-joins, implicit cartesian)
6. Reject queries containing SQL comments (/* or --)
   (reject entirely - don't strip, stripping changes query meaning)
7. Block system catalog: pg_shadow, pg_authid, pg_roles
8. Auto-append LIMIT 1000 if missing
9. Enforce response size limit (e.g. 1MB) - catches STRING_AGG
   and other aggregate dumps that bypass row limits
10. Block computed ORDER BY (prevents function injection)
11. Block subqueries in ORDER BY (O(n^2) attacks)
12. Limit subquery depth (max 3 SELECT keywords)

The Risk

Regex-based SQL validation works on raw text - it cannot understand SQL structure. Attackers exploit this gap with CTEs (WITH t AS (...) SELECT FROM t a, t b), table aliases, nested function calls, and implicit joins that look different in text but produce the same dangerous execution plan. Every regex bypass the pen tester found in Round 3 was structural - the SQL was semantically identical to a blocked pattern but syntactically different enough to pass text-based checks.

The Solution

Add a SQL parser (sqlglot) as a structural validation layer on top of your regex checks. The parser builds an Abstract Syntax Tree (AST) and validates the actual query structure: how many tables appear in each SELECT's FROM clause, which functions are called regardless of nesting or aliasing. Keep the regex layer as the first line of defense (fast, catches obvious attacks) and use the parser as a second pass for structural checks that regex cannot handle. sqlglot supports both Postgres and DuckDB dialects and is pure Python with no C dependencies.

The Fix

import sqlglot
from sqlglot import exp as sqlglot_exp

def validate_sql_structure(sql, engine="postgres"):
    dialect = "duckdb" if engine == "duckdb" else "postgres"
    try:
        parsed = sqlglot.parse_one(sql, dialect=dialect)
    except sqlglot.errors.ParseError:
        return "Invalid SQL syntax"

    # Block multiple table sources per SELECT (catches cartesian products,
    # CTE alias bypass, implicit joins via FROM a, b)
    for select in parsed.find_all(sqlglot_exp.Select):
        from_clause = select.find(sqlglot_exp.From)
        if not from_clause:
            continue
        from_tables = list(from_clause.find_all(sqlglot_exp.Table))
        join_tables = []
        for join in select.find_all(sqlglot_exp.Join):
            if join.find_ancestor(sqlglot_exp.Select) is select:
                join_tables.extend(join.find_all(sqlglot_exp.Table))
        if len(from_tables) + len(join_tables) > 1:
            return "Multiple table sources not allowed"

    # Block dangerous functions via AST (catches nested/aliased usage)
    BLOCKED = {"REPEAT", "LPAD", "RPAD", "GENERATE_SERIES", "MD5", "SHA256"}
    for func in parsed.find_all(sqlglot_exp.Func):
        name = func.name.upper() if hasattr(func, 'name') else ""
        if name in BLOCKED:
            return f"Blocked function: {name}"
    return None

The Risk

Even with API key authentication, a compromised client or misconfigured admin tool can issue DELETE FROM critical_table. If your endpoint allows write operations through a proxy-to-database pattern, restricting which tables are writable is a last-resort guard.

The Solution

Maintain a list of table names that are allowed for write operations (insert, update, delete). Before running any write query, extract the table name from the SQL and check it against your list. If the table isn't on the list, reject the query. This is a safety net - even if someone has valid credentials, they can only modify approved tables.

The Fix

ALLOWED_TABLES = {"users", "sessions", "audit_log"}

import re
match = re.search(
    r'\\b(?:INTO|UPDATE|FROM|DELETE\\s+FROM)\\s+["\\'\\']?(\\w+)',
    sql, re.IGNORECASE
)
if match and match.group(1).lower() not in ALLOWED_TABLES:
    raise HTTPException(400, detail="Operation not allowed")

The Risk

Returning str(e) to clients in error responses leaks internal details: file paths, table names, database versions, library versions. Attackers use this information to map your infrastructure and craft targeted attacks. Health endpoints that return version info are equally dangerous.

The Solution

Never send raw error messages to the user. Log the full error details on your server for debugging, but return only a generic, helpful message to the client like "Query failed - check your SQL syntax." Health check endpoints should return just "status: ok" without version numbers, file paths, or configuration details.

The Fix

# WRONG - leaks internals
raise HTTPException(400, detail=f"Error: {str(e)}")

# RIGHT - log internally, return generic message
logger.error(f"Query error: {e}")
raise HTTPException(400, detail="Query failed. Check SQL syntax.")

# SAFETY NET - global exception handler catches anything
# that slips through individual try/except blocks
@app.exception_handler(Exception)
async def global_exception_handler(request: Request, exc: Exception):
    logger.error(f"Unhandled: {request.url.path}: {exc}", exc_info=True)
    return JSONResponse(status_code=500,
        content={"detail": "Internal server error"})

# Health endpoints - only return status
@app.get("/health")
async def health():
    return {"status": "ok"}  # No versions, paths, or config

The Risk

Non-public endpoints without authentication are discoverable and callable by anyone. If the API key defaults to an empty string when the environment variable isn't set, every request passes validation - this is a common deployment mistake that silently disables auth.

The Solution

Require an API key in a request header for every non-public endpoint. At startup, check that the API key environment variable is actually set - if it's missing, refuse to start the server. This "fail-secure" approach ensures you never accidentally run without authentication because someone forgot to set the variable during deployment.

The Fix

API_KEY = os.getenv("API_KEY")
if not API_KEY:
    raise RuntimeError("API_KEY not configured")  # fail-secure

async def verify_api_key(request: Request):
    key = request.headers.get("X-API-Key", "")
    if key != API_KEY:
        raise HTTPException(401, detail="Invalid API key")

@app.post("/api/endpoint", dependencies=[Depends(verify_api_key)])

The Risk

Behind Cloudflare or nginx, request.client.host returns the proxy's IP, not the actual user's IP. This means all users share one "IP" for rate limiting - either everyone gets blocked or nobody does. Worse, X-Forwarded-For, X-Real-IP, and any custom headers (like X-Original-Client-IP) can be freely set by the client - an attacker sends a fake header to bypass per-IP rate limiting entirely. Only CF-Connecting-IP is safe because Cloudflare sets it from the actual TCP connection at the edge, overwriting any client-supplied value.

The Solution

Write a helper function that prioritizes cf-connecting-ip first - it is the only header that cannot be spoofed by the client. Cloudflare determines the client IP from the TCP connection itself (the IP layer of the network stack, not any HTTP header). All other headers (X-Forwarded-For, X-Real-IP, custom headers) are just HTTP headers that any client can set to any value. Fall back to x-forwarded-for and request.client.host for non-Cloudflare environments.

The Fix

def get_client_ip(request: Request) -> str:
    for header in ['cf-connecting-ip',
                   'x-forwarded-for',
                   'x-real-ip']:
        val = request.headers.get(header, '')
        if val:
            return val.split(',')[0].strip()
    return request.client.host if request.client else 'unknown'

# CRITICAL: SlowAPI ignores this unless you override key_func
limiter = Limiter(key_func=get_client_ip)  # NOT get_remote_address

The Risk

Without signature verification, anyone who discovers your webhook URL can POST fake events - fake payment confirmations, fake user signups, fake booking notifications. Your backend processes them as real, leading to data corruption or unauthorized actions.

The Solution

When receiving a webhook, verify the signature that the sender attached. The sender (Stripe, GitHub, Brevo, etc.) signs each webhook with a shared secret - your server recalculates the signature and compares. If they don't match, the webhook is fake. Also reject webhooks older than 5 minutes to prevent replay attacks where someone resends a captured webhook later.

The Fix

import hmac, hashlib

def verify_webhook(payload: bytes, signature: str, secret: str):
    expected = hmac.new(
        secret.encode(), payload, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(f"sha256={expected}", signature)

raw_body = await request.body()
sig = request.headers.get("x-webhook-signature", "")
if not verify_webhook(raw_body, sig, os.getenv("WEBHOOK_SECRET")):
    raise HTTPException(401, detail="Invalid signature")

# Reject old webhooks (replay protection)
timestamp = int(request.headers.get("x-webhook-timestamp", "0"))
if abs(time.time() - timestamp) > 300:  # 5 minutes
    raise HTTPException(401, detail="Webhook expired")

The Risk

If any endpoint fetches a URL supplied by the client (proxy endpoints, URL preview generators), attackers can use your server to reach internal services: AWS metadata at 169.254.169.254 (leaks credentials), localhost admin panels, or private network scanning. Your server becomes a weapon against your own infrastructure.

The Solution

Maintain a list of approved domains and URL paths that your server is allowed to fetch. When a user provides a URL, check that the domain and path are on your approved list before making the request. Block any requests to internal addresses like localhost or cloud metadata endpoints. This prevents attackers from using your server as a proxy to reach things they shouldn't.

The Fix

# Python - domain allowlist + redirect validation
ALLOWED_DOMAINS = {"api.example.com", "cdn.example.com"}
from urllib.parse import urlparse

def validate_url(url: str):
    parsed = urlparse(url)
    if parsed.scheme not in ("https",):
        raise HTTPException(400, "HTTPS only")
    if parsed.hostname not in ALLOWED_DOMAINS:
        raise HTTPException(400, "Domain not allowed")

validate_url(user_url)  # check initial URL

# CRITICAL: disable auto-redirect, validate each hop
resp = httpx.get(user_url, follow_redirects=False)
while resp.is_redirect:
    redirect_url = str(resp.next_request.url)
    validate_url(redirect_url)  # check EVERY redirect target
    resp = httpx.get(redirect_url, follow_redirects=False)

# Also enforce response size cap
MAX_SIZE = 50 * 1024 * 1024  # 50MB

The Risk

Without request logging, you can't detect attacks, debug failures, or understand usage patterns. When something goes wrong, you're flying blind. Monitoring should log endpoints, status codes, and response times - not request bodies or PII.

The Solution

Add a monitoring middleware that automatically logs every API request - which endpoint was called, whether it succeeded or failed, and how long it took. Send these logs to a centralized dashboard so you can spot unusual patterns (sudden spike in errors, slow queries, unknown endpoints being probed). Only log operational data, never personal information.

The Fix

pip install your-api-monitor  # or any monitoring middleware

# Use try/except - if package isn't installed, app still starts
try:
    from your_api_monitor import APIMonitorMiddleware
    app.add_middleware(APIMonitorMiddleware,
        app_name="YOUR_APP_NAME",
        include_prefixes=("/api/", "/analyze"),
    )
except ImportError:
    pass  # monitoring unavailable, app runs without it

# Env vars: API_MONITOR_URL, API_MONITOR_KEY

The Risk

If your backend accepts file uploads without validation, attackers can upload executable files (.py, .sh, .exe), oversized files that fill your disk, or files disguised with fake extensions (.jpg that is actually a .html with embedded scripts). If uploaded files are served back to users from your domain, an uploaded HTML file executes in your site's security context.

The Solution

Validate every uploaded file on three levels: check the file extension against an allowlist (only accept the types your app actually needs), enforce a maximum file size so nobody fills your disk, and store uploaded files in a location where they cannot be executed by the server. Never trust the browser's Content-Type header - check the actual file contents. Serve downloads with Content-Disposition: attachment so browsers download instead of rendering.

The Fix

import os
ALLOWED_EXTENSIONS = {".csv", ".xlsx", ".parquet", ".duckdb"}
MAX_FILE_SIZE_MB = 50

async def validate_upload(file: UploadFile):
    # 1. Check extension
    ext = os.path.splitext(file.filename)[1].lower()
    if ext not in ALLOWED_EXTENSIONS:
        raise HTTPException(400, "File type not allowed")

    # 2. Check size (read in chunks, don't load all into memory)
    size = 0
    while chunk := await file.read(8192):
        size += len(chunk)
        if size > MAX_FILE_SIZE_MB * 1024 * 1024:
            raise HTTPException(413, "File too large")
    await file.seek(0)  # reset for actual processing

    # 3. Serve with safe headers
    # Content-Disposition: attachment (download, don't render)
    # X-Content-Type-Options: nosniff (don't guess type)

The Risk

Python's requests.post(..., verify=False) disables SSL certificate checking, enabling man-in-the-middle attacks. An attacker on the network path can intercept and modify traffic between your backend and other services - reading API keys, injecting malicious responses, or stealing data in transit. This is especially common in backends that were set up during development and never fixed for production.

The Solution

Always use verify=True (the default) for external API calls. When the target is behind Cloudflare or has a valid certificate, there is no excuse for verify=False. For Docker-internal calls where services communicate without SSL, use an internal URL variable that explicitly skips SSL only for known-internal addresses. This way, internal calls use Docker networking (no SSL needed) and external calls always verify certificates.

The Fix

# WRONG - disables all SSL verification
resp = requests.post(url, json=data, verify=False)

# RIGHT - verify certificates for external calls
resp = requests.post(url, json=data)  # verify=True is default

# For Docker-internal services (no SSL):
BACKEND_URL = os.getenv("BACKEND_URL")         # external, verified
BACKEND_URL_INTERNAL = os.getenv("BACKEND_URL_INTERNAL")  # Docker alias

async def call_backend(path, data):
    url = BACKEND_URL_INTERNAL or BACKEND_URL
    verify = BACKEND_URL_INTERNAL is None  # skip SSL only for internal
    return requests.post(f"{url}{path}", json=data, verify=verify)

The Risk

Item 1.14 says "don't log PII in console.log" - that's about careless logging in serverless functions visible to anyone with dashboard access. But for incident response, you NEED request bodies and client IPs. Without them, you can't answer "what happened?" after an attack - you can see that endpoints were called, but not what payloads were sent (SQL injection attempts, credential stuffing patterns, malformed requests from scanning tools). The question isn't whether to capture PII, it's how to capture it safely with controls and auto-deletion.

The Solution

Set up a centralized logging pipeline: every backend sends request metadata (endpoint, status, response time, client IP, request body) to a dedicated logging service, which stores it in a database with a retention policy. Keep identifiable data (IP, request body) for 30 days for incident response, then auto-NULL it via a daily cron job. Keep permanent non-identifiable hashes (SHA256 of request body) for pattern analysis. All backends flow to one dashboard so you can correlate attacks across services - during an incident, you need one place to look, not 30 containers to SSH into.

The Fix

# The pipeline:
# Backend → monitoring middleware → Logger Service → DB → Dashboard
#                                                        ↓
#                                          Daily cron: NULL PII > 30 days

# Each backend: 3 lines + 2 env vars
try:
    from your_api_monitor import APIMonitorMiddleware
    app.add_middleware(APIMonitorMiddleware,
        app_name="APP_NAME",
        include_prefixes=("/api/",),
    )
except ImportError:
    pass
# Env vars: API_MONITOR_URL, API_MONITOR_KEY

# PII cleanup endpoint (called by daily cron)
@app.post("/admin/cleanup-raw-data")
async def cleanup_raw_data():
    retention = int(os.getenv("PII_RETENTION_DAYS", "30"))
    result = await db.execute(
        "UPDATE api_logs SET client_ip = NULL, request_body = NULL "
        "WHERE created_at < NOW() - INTERVAL '%s days' "
        "AND client_ip IS NOT NULL", retention
    )
    return {"nullified": result.rowcount}
# request_body_hash stays - count patterns without identifying sender

The Risk

Endpoints that generate reports (PDF, HTML, CSV) create files on disk. Without cleanup, these accumulate indefinitely - filling the disk, slowing the server, and potentially exposing old reports to anyone who guesses the filename pattern.

The Solution

Add cleanup logic that deletes generated files older than a set period (e.g., 2 hours). Run cleanup on each new request (lazy cleanup) or via a scheduled cron job. Use a dedicated output directory that's easy to sweep.

The Fix

import os, time
from pathlib import Path

OUTPUT_DIR = Path("./output")
MAX_AGE_HOURS = 2

def cleanup_old_files():
    """Delete generated files older than MAX_AGE_HOURS"""
    cutoff = time.time() - (MAX_AGE_HOURS * 3600)
    for f in OUTPUT_DIR.glob("*"):
        if f.is_file() and f.stat().st_mtime < cutoff:
            f.unlink()

# Call at the start of each report generation endpoint
@app.post("/generate-report")
async def generate_report(...):
    cleanup_old_files()  # sweep old files first
    # ... generate new report

The Risk

SQL validation (item 2.4) blocks write keywords in queries, but regex-based validation can have gaps - clever encoding, dialect-specific syntax, or new SQL features might bypass it. If the database connection itself allows writes, a validation bypass means data can be modified or deleted.

The Solution

Enforce read-only mode at both the SQL validation level AND the database connection level. This is defense in depth - even if SQL validation misses something, the database connection itself will reject any write operation.

The Fix

# Postgres: use a read-only database role
CREATE ROLE readonly_user WITH LOGIN PASSWORD 'xxx';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
# Connect with this role for all query endpoints

# DuckDB: open in read-only mode
conn = duckdb.connect("data.duckdb", read_only=True)

# Application level: validate BEFORE database level
validated_sql = validate_sql(raw_sql)  # regex + parser
result = readonly_conn.execute(validated_sql)  # read-only conn

The Risk

Without indexes, every query scans the entire table row by row. On a table with 10K+ rows, this makes queries slow enough that an attacker can tie up your database connections with a few concurrent requests. Indexes turn full scans into near-instant lookups.

The Solution

Create indexes on columns that you frequently filter, sort, or group by. Think of an index like a book's table of contents - instead of reading every page to find a topic, you jump straight to it. This makes queries dramatically faster and harder to abuse, because even a malicious query resolves quickly instead of tying up the database.

The Fix

-- Add indexes on columns used in WHERE, GROUP BY, ORDER BY, JOIN
CREATE INDEX idx_col ON table_name(column_name);

-- For composite queries
CREATE INDEX idx_multi ON table_name(col1, col2);

The Risk

A single runaway query (or a deliberately crafted one) can consume 100% CPU for minutes, blocking all other queries. Without a timeout, your database becomes unresponsive until you manually kill the query. This is an easy denial-of-service vector.

The Solution

Set a maximum time limit on every database user role. 15 seconds is a good starting point for read-only analytics APIs - most legitimate queries finish in under 5 seconds. If any query takes longer than that, the database automatically kills it. This prevents a single slow or malicious query from locking up your entire database and affecting all other users. Also set the timeout at the application level (e.g. PG_STATEMENT_TIMEOUT_MS environment variable) so it applies to every connection in the pool.

The Fix

-- Set on every role that connects
ALTER ROLE myuser SET statement_timeout = '15s';

The Risk

If your application connects as the database owner (the postgres superuser), a SQL injection vulnerability gives the attacker full control: drop tables, read password hashes, modify data. A restricted read-only role limits the damage - even a successful injection can only read data from allowed tables.

The Solution

Create a separate database user that can only read data (SELECT) from specific tables you choose. Connect your application using this restricted user instead of the all-powerful admin account. Also block access to system tables that contain password hashes and configuration. Even if an attacker finds a way to run SQL, they can only read - not delete, modify, or access sensitive system data.

The Fix

CREATE ROLE app_readonly WITH LOGIN PASSWORD '...';
GRANT SELECT ON specific_table TO app_readonly;
ALTER ROLE app_readonly SET default_transaction_read_only = on;

-- Revoke access to system schemas
REVOKE ALL ON SCHEMA pg_catalog FROM app_readonly;
REVOKE ALL ON SCHEMA information_schema FROM app_readonly;

The Risk

Supabase exposes a PostgREST API publicly. Your anon key is visible in frontend code. Without Row Level Security (RLS), anyone with that key can INSERT, UPDATE, and DELETE any row in any table. The anon key is not a secret - RLS is your real access control. But enabling RLS alone is not enough - a policy like "Users can update their own profile" with USING (auth.uid() = user_id) applies to ALL columns. If the table has sensitive columns (is_admin, status, subscription_tier, limits), the user can update those on their own row. One API call = privilege escalation.

The Solution

Enable Row Level Security on every table and create policies that define who can do what. For read-only data, allow SELECT only. For user-writable tables, be extremely careful about UPDATE policies - they grant write access to every column on matching rows. Keep sensitive columns (roles, subscription status, permissions, usage limits) in separate tables that users can never write to directly. Billing webhooks and server-side logic should write to those tables via service_role. If you cannot restructure the schema, add BEFORE UPDATE triggers to reject changes to protected columns. If tables are backend-only, revoke all access from the anonymous role entirely.

The Fix

ALTER TABLE mytable ENABLE ROW LEVEL SECURITY;
CREATE POLICY "read_only" ON mytable FOR SELECT USING (true);

-- If backend-only (no frontend needs anon access):
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM anon;

-- DANGER: This policy lets users update ANY column on their row
-- including is_admin, role, subscription_tier, limits!
CREATE POLICY "update_own" ON profiles
  FOR UPDATE USING (auth.uid() = user_id);

-- FIX: Protect sensitive columns with a trigger
CREATE OR REPLACE FUNCTION protect_sensitive_columns()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.status != OLD.status OR NEW.limits != OLD.limits THEN
    RAISE EXCEPTION 'Cannot modify protected columns';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER guard_sensitive
  BEFORE UPDATE ON app_users
  FOR EACH ROW EXECUTE FUNCTION protect_sensitive_columns();

The Risk

Without a properly configured connection pool, your app creates a new database connection for every request (slow) or runs out of connections under load (crash). Cold-start connections add latency. Without an acquire timeout, requests queue forever during connection exhaustion.

The Solution

Use a connection pool that keeps a few database connections ready at all times (pre-warmed) so requests don't wait for new connections to be created. Set a maximum number of connections so your database doesn't get overwhelmed, and set a timeout so requests fail quickly rather than hanging forever if all connections are busy.

The Fix

# asyncpg - pre-warm and configure limits
pool = await asyncpg.create_pool(
    dsn=DATABASE_URL,
    min_size=3,       # pre-warmed connections
    max_size=6,       # upper limit
    command_timeout=15,
    init=init_conn    # set read-only + statement timeout
)

The Risk

Postgres functions marked SECURITY DEFINER execute with the function owner's privileges, completely bypassing Row Level Security. If such a function accepts user-supplied identity parameters (email, user_id, org_id), any authenticated user can impersonate anyone else. For example, a function increment_usage(p_email text, ...) SECURITY DEFINER lets any user insert or update usage records for ANY email - complete identity spoofing that RLS cannot prevent.

The Solution

Audit all SECURITY DEFINER functions in your database. Custom functions should almost never need SECURITY DEFINER - use the default SECURITY INVOKER instead. If a function genuinely needs elevated privileges, never accept user-supplied identity parameters. Pull identity from the JWT using auth.email() or auth.uid() inside the function body. After fixing a function signature, remember that Postgres treats different parameter counts as separate overloads - you must explicitly DROP the old vulnerable version.

The Fix

-- Find all SECURITY DEFINER functions
SELECT n.nspname, p.proname, pg_get_functiondef(p.oid)
FROM pg_proc p JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE p.prosecdef = true
  AND n.nspname NOT IN ('pg_catalog','information_schema');

-- BAD: accepts user-supplied email (spoofable)
CREATE FUNCTION increment_usage(p_email text, p_app text)
  SECURITY DEFINER AS $$ ...
  INSERT INTO usage (email, ...) VALUES (p_email, ...) $$;

-- GOOD: pulls email from JWT (unforgeable)
CREATE FUNCTION increment_usage(p_app text)
  SECURITY DEFINER AS $$ ...
  INSERT INTO usage (email, ...) VALUES (auth.email(), ...) $$;

-- After fixing: DROP the old overload explicitly
DROP FUNCTION increment_usage(text, text, text, text, numeric);

The Risk

Supabase defaults grant the authenticated role full CRUD permissions (INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES) on every table - regardless of your RLS policies. This means if RLS is accidentally disabled on any table, or a permissive policy is added carelessly, authenticated users instantly have full write access. RLS is one layer. Grants are another. You need both locked down.

The Solution

After setting up RLS policies, audit and tighten the underlying table grants so the authenticated role only has the specific permissions that match your actual RLS policies. Read-only data tables (reference data, public datasets, lookup tables) should have SELECT-only grants. User-writable tables should have only the operations their RLS policies allow (e.g., SELECT + INSERT + UPDATE for a files table, not DELETE + TRUNCATE). This is defense-in-depth - even without RLS, damage is limited to what the grants allow.

The Fix

-- Audit current grants
SELECT grantee, table_name, privilege_type
FROM information_schema.table_privileges
WHERE table_schema = 'public'
  AND grantee IN ('anon', 'authenticated')
ORDER BY table_name;

-- Lock down read-only data tables
REVOKE INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES
  ON my_readonly_table FROM authenticated;

-- Lock down user-writable tables (keep only needed ops)
REVOKE TRUNCATE, TRIGGER, REFERENCES
  ON user_files FROM authenticated;

-- Lock down tables users should never write to
REVOKE UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES
  ON app_users FROM authenticated;

The Risk

DuckDB can read and write files on the server's filesystem by default. A crafted query can read /etc/passwd, write malicious files, or load external data from the network. In a web-facing application, this is equivalent to giving users shell access to your server.

The Solution

Open the DuckDB database in read-only mode so no data can be modified, and disable external access so queries cannot read files from disk or fetch data from the internet. These two settings together ensure that DuckDB can only query the data already inside the database file - nothing else on your server.

The Fix

conn = duckdb.connect(filepath, read_only=True)
conn.execute("SET enable_external_access=false")

The Risk

DuckDB runs in-process - not in a separate server. Without limits, a single query can consume all available RAM and CPU cores, starving your web server and every other process on the machine. Unlike Postgres, there's no separate process to kill.

The Solution

Set explicit limits on how much memory and how many CPU cores DuckDB is allowed to use. For example, cap it at 512MB of RAM and 2 CPU threads. This ensures that even a heavy query leaves enough resources for your web server and other services to keep running normally.

The Fix

conn.execute("SET memory_limit='512MB'")
conn.execute("SET threads=2")

The Risk

When you cancel an asyncio task in Python, it does NOT stop the DuckDB C++ engine running underneath. The query keeps consuming CPU and memory even though the Python coroutine has been cancelled. You must explicitly call conn.interrupt() to kill the query.

The Solution

When a DuckDB query times out, you must explicitly tell the DuckDB engine to stop by calling its interrupt method, then close the connection. Simply cancelling the Python task is not enough - the database engine runs in C++ underneath and keeps going unless you directly tell it to stop.

The Fix

# On timeout:
conn.interrupt()          # kills the C++ query engine
await asyncio.sleep(0.1)  # let engine acknowledge interrupt
conn.close()              # release resources

The Risk

Even with DuckDB's memory_limit set, a bug or edge case can cause the process to exceed it. Without Docker container limits, one runaway DuckDB container can starve every other service on the same server - databases, web servers, monitoring.

The Solution

Set memory and CPU limits at the Docker container level as a second safety net. Even if DuckDB's own memory limit is bypassed due to a bug, the container will be capped. This protects every other service running on the same server from being starved by one runaway container.

The Fix

# Docker / Coolify container settings
memory: 1GB
swap: 2GB
cpus: 2

The Risk

DuckDB uses file-level locking. If a process crashes or is killed while holding a write lock, it can leave behind a stale .wal (write-ahead log) file that blocks all subsequent connections. In read-only mode, multiple connections work fine - but if ANY process opens the file in write mode (even briefly, like a data import script), it blocks all other connections until it releases the lock.

The Solution

Always open DuckDB in read-only mode for web-facing applications (see 4.1). Keep write access limited to offline processes (data imports, migrations) that run one at a time. If a stale .wal file blocks connections after a crash, you may need to open the database in write mode once to recover it, then switch back to read-only. Monitor for .wal files as part of your health checks.

The Fix

# Web-facing app: always read-only (no lock contention)
conn = duckdb.connect(filepath, read_only=True)

# Data import script: write mode, one process at a time
conn = duckdb.connect(filepath, read_only=False)
# ... import data ...
conn.close()  # releases lock

# Recovery: if stale .wal blocks read-only connections
# Option 1: open write mode briefly to flush WAL
conn = duckdb.connect(filepath, read_only=False)
conn.close()
# Option 2: delete .wal file (LAST RESORT - may lose data)

The Risk

Unlike Postgres (separate server process), DuckDB runs inside your FastAPI process. A heavy DuckDB query blocks the Python asyncio event loop, freezing ALL concurrent handling - health checks stop responding, rate limit checks can't execute, and timeout logic can't fire. Your entire API becomes unresponsive for the duration of the query, not just the endpoint that triggered it.

The Solution

Always run DuckDB queries in a ThreadPoolExecutor so they execute in a separate thread, leaving the asyncio event loop free to handle other requests. Without this, your timeout and interrupt logic (item 4.3) can't even fire - the event loop is blocked, so the timeout coroutine never gets a chance to run. This is also why concurrent request limits (item 2.3) are critical for DuckDB backends.

The Fix

import asyncio

# WRONG - blocks the event loop
@app.get("/api/query")
async def query(request: Request):
    result = conn.execute(sql).fetchall()  # blocks everything

# RIGHT - run in thread, event loop stays responsive
@app.get("/api/query")
async def query(request: Request):
    loop = asyncio.get_event_loop()
    result = await loop.run_in_executor(
        None, execute_duckdb_query, sql
    )
    return result

The Risk

DNS records set to "grey cloud" (DNS-only) expose your server's real IP address. Once an attacker knows the IP, they can bypass Cloudflare entirely - all DDoS protection, WAF rules, and rate limiting become useless. They hit your server directly. This is the #1 real-world IP spoofing risk: without Cloudflare in the path, CF-Connecting-IP can be trivially spoofed (it's just an HTTP header), and your get_client_ip function that trusts it first will accept any value the attacker sends.

The Solution

In your Cloudflare DNS settings, make sure every record has the orange cloud icon (proxied mode) turned on - not the grey cloud (DNS-only). When proxied, all traffic goes through Cloudflare first, which hides your server's real IP address and applies all your security rules. With the grey cloud, your server's IP is visible to anyone. For defense in depth: configure your server firewall to ONLY accept connections from Cloudflare's published IP ranges, and enable Cloudflare Authenticated Origin Pulls. This way, even if the origin IP leaks, direct connections are rejected.

The Fix

All DNS records must be orange cloud (proxied).
In Cloudflare DNS settings, toggle the proxy
icon to orange for every A/AAAA/CNAME record.

The Risk

Some subdomains must be grey cloud (DNS-only) because third-party services like Auth0, Clerk, or AWS RDS require direct CNAME resolution. These subdomains bypass all Cloudflare protection - no rate limiting, no WAF, no IP blocking. If you don't track which domains are grey and why, you lose visibility into your actual attack surface.

The Solution

Maintain a list of every grey-clouded subdomain and the reason it must be grey (e.g., "auth.example.com - Auth0 requires direct CNAME"). Periodically audit this list: if a service is decommissioned, either delete the DNS record or switch it to orange cloud. Ensure no origin servers (your VPS, your hosting) are ever exposed through grey-cloud records - only third-party CNAMEs should be grey.

The Fix

# Audit grey-cloud records via Cloudflare API
# List all DNS records and filter for proxied=false
curl -s "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \\
  -H "Authorization: Bearer {token}" | \\
  jq '.result[] | select(.proxied==false) | {name, type, content}'

# Expected grey cloud: third-party CNAMEs only
# auth.example.com    -> Auth0 tenant (required)
# clerk.example.com   -> Clerk frontend (required)
# db.example.com      -> managed DB (required)

# NOT acceptable: your VPS IP exposed via grey cloud
# app.example.com -> 1.2.3.4  (must be orange!)

The Risk

Bots and automated tools use fake or missing User-Agent headers. Without Browser Integrity Check, these requests reach your application unchallenged. The Security Level setting controls how aggressively Cloudflare challenges suspicious IPs - the default is too permissive for sites under active attack.

The Solution

Turn on three settings in Cloudflare: Browser Integrity Check (blocks requests with suspicious or missing browser headers), Bot Fight Mode (challenges known bot fingerprints), and set the Security Level to Medium or High (challenges visitors from IP addresses with a bad reputation). These are toggle switches in your Cloudflare dashboard - no code needed.

The Fix

Cloudflare dashboard > Security > Settings:

- Browser Integrity Check: ON
  (blocks suspicious User-Agent headers)
- Security Level: "Medium" or "High"
  ("I'm Under Attack" mode for active DDoS only)
- Bot Fight Mode: ON
  (challenges known bot fingerprints)

The Risk

Browser Integrity Check and Bot Fight Mode catch known bad signatures, but many automated tools (scrapers, vulnerability scanners, credential stuffers) use real browser headers. They pass basic checks and hit your frontends unchallenged. Without a JS challenge, any script that can send HTTP requests can access your application pages.

The Solution

Create a Cloudflare WAF custom rule that applies a JS Challenge to all your frontend domains. Real browsers solve the challenge transparently (invisible to users). Automated scripts and bots cannot execute JavaScript, so they get blocked with a 403. List all your frontend hostnames in the rule expression. If you have API paths that legitimate bots need to access (AI agents, webhooks, health checks), add path exclusions to the same rule so those paths return 200 without a challenge.

The Fix

Cloudflare dashboard > Security > WAF > Custom rules

Action: JS Challenge
Expression example (multiple frontends):
  (http.host eq "app.example.com") or
  (http.host eq "dashboard.example.com") or
  (http.host eq "www.example.com" and
    not starts_with(http.request.uri.path, "/api/webhook") and
    not starts_with(http.request.uri.path, "/robots.txt"))

# Browsers: pass transparently (no visible CAPTCHA)
# Bots/scrapers: blocked (cannot execute JS)
# Excluded paths: return 200 to all clients

The Risk

Cloudflare's free tier provides DDoS protection at the network level but NOT HTTP-level (L7) rate limiting by default. Without a WAF rate limit rule, an attacker can flood your application endpoints with legitimate-looking HTTP requests that pass through Cloudflare unblocked.

The Solution

Create a rate limiting rule in Cloudflare's WAF that blocks any IP address exceeding a threshold (e.g., 50 requests per 10 seconds). This stops HTTP-level floods before they reach your server. The free tier allows one rate limit rule with a minimum 10-second window. Make it zone-wide so it covers all subdomains.

The Fix

Cloudflare dashboard > Security > WAF > Rate limiting rules

Rule: 50 requests per 10 seconds per IP
Action: Block for 10 seconds
Characteristics: MUST include cf.colo.id

Expression: (true)  - applies to all subdomains

Note: Free tier = 1 rule only, 10s minimum period.

The Risk

The free WAF rate limit (one rule, one threshold) treats all domains equally. But frontends need higher limits than backends - a React app sends 30-40 requests on page load (JS, CSS, images, API calls), while a backend API might only need 10 requests per minute per user. A single threshold either blocks legitimate frontend users or leaves backends wide open.

The Solution

Deploy a Cloudflare Worker that intercepts traffic at the edge and applies different rate limit thresholds per domain. Use Cloudflare's native rate limit bindings (defined in wrangler.toml) so counters are managed at the edge with zero additional latency. Map each domain to a tier - for example, frontends at 150 requests/60 seconds, backends at 10 requests/60 seconds, sensitive endpoints at 20 requests/60 seconds. Add a wildcard catch-all so new domains automatically get a moderate default.

The Fix

# wrangler.toml - define rate limit tiers as bindings
[[unsafe.bindings]]
name = "BACKEND_STRICT"
type = "ratelimit"
namespace_id = "1"
simple = { limit = 10, period = 60 }

[[unsafe.bindings]]
name = "FRONTEND_STANDARD"
type = "ratelimit"
namespace_id = "2"
simple = { limit = 150, period = 60 }

# src/index.js - map domains to tiers
const DOMAIN_CONFIG = {
  "api.example.com":       { limiter: "BACKEND_STRICT" },
  "dashboard.example.com": { limiter: "FRONTEND_STANDARD" },
  // ... add each domain
};

// Worker checks rate limit, returns 429 if exceeded
// Domains not in config get a moderate catch-all tier
// Deploy: npx wrangler deploy
// Add Worker Route per domain in Cloudflare dashboard

The Risk

When you identify a malicious IP or subnet (from attack logs, vulnerability scanners, or brute-force attempts), blocking it at the application level still lets the traffic reach your server - consuming bandwidth and CPU for every rejected request. The attacker can also try other subdomains or endpoints.

The Solution

Block malicious IPs at the Cloudflare zone level using IP Access Rules. Traffic from blocked IPs is dropped at the edge before it reaches your server - zero bandwidth, zero CPU cost. Block entire /24 ranges when an attacker operates from a known bulletproof hosting provider. Document each block with the reason and evidence so you can audit and clean up later.

The Fix

# Block an IP range at Cloudflare edge
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/firewall/access_rules/rules" \\
  -H "Authorization: Bearer {token}" \\
  -H "Content-Type: application/json" \\
  -d '{
    "mode": "block",
    "configuration": {
      "target": "ip_range",
      "value": "185.177.72.0/24"
    },
    "notes": "Bulletproof hosting. Path traversal attack on 2026-03-01."
  }'

# List all blocked IPs/ranges
curl -s "https://api.cloudflare.com/client/v4/zones/{zone_id}/firewall/access_rules/rules" \\
  -H "Authorization: Bearer {token}" | jq '.result[] | {value: .configuration.value, notes}'

The Risk

API keys in committed files are permanently in git history - even if you delete the file later. Bots scan GitHub continuously (including private repos via leaked PATs) and can find your keys within minutes. A single committed Brevo API key lets attackers send email as your domain.

The Solution

Store all secrets (API keys, database passwords, tokens) as environment variables on your hosting platform - never in code files. If a secret is accidentally committed to git, rotate it immediately (generate a new one and revoke the old one). Simply deleting the file doesn't help because git keeps the full history. Scan your repo periodically for accidental exposures.

The Fix

# Use environment variables only
API_KEY = os.getenv("API_KEY")
if not API_KEY:
    raise RuntimeError("API_KEY not configured")

# Scan for accidentally committed secrets
git ls-files | grep -i "env|secret|key|token"

# If found, rotate immediately - don't just delete the file

The Risk

Missing .gitignore entries cause secrets and large files to be committed accidentally. A .env file with database URLs, an SSL private key (.pem), or a node_modules folder can all end up in your repo. Once committed, removing them from the working tree doesn't remove them from git history.

The Solution

Add a .gitignore file at the root of every repository that lists all files and folders that should never be committed: .env files (secrets), private keys (.pem, .key), dependency folders (node_modules, .venv), and build outputs (dist, build). This is a one-time setup that prevents accidental exposure of sensitive files.

The Fix

# Minimum .gitignore for every repo
.env
.env.local
.env.*.local
.env.vercel.check
node_modules/
__pycache__/
.venv/
dist/
build/
*.pem
*.key

The Risk

AI coding tools suggest packages constantly, and typosquatted packages (names that look like popular ones but are malicious) specifically target developers who install without verifying. A single malicious dependency can exfiltrate environment variables, inject backdoors, or compromise your entire build pipeline. This risk multiplies when AI assistants generate install commands - they can hallucinate package names that happen to be typosquats.

The Solution

Before installing any package, verify it is the official one - check the npm/PyPI page, look at download counts, check the publisher. Run npm audit and pip audit regularly and fix HIGH/CRITICAL vulnerabilities before deploying. Pin your dependency versions so updates don't silently introduce malicious code. When an AI suggests a package you haven't used before, verify it exists and is legitimate before running the install command.

The Fix

# NPM: audit and fix
npm audit
npm audit fix
# Pin versions in package.json (no ^ or ~)
"dependencies": { "express": "4.18.2" }  # exact

# Python: audit with pip-audit
pip install pip-audit
pip-audit
# Pin versions in requirements.txt
fastapi==0.115.0  # exact, no >=

# Before installing ANY new package:
# 1. Check npm/PyPI page - verify publisher, downloads
# 2. Compare name character-by-character (no typosquats)
# 3. Check: is this the package the AI meant?
# 4. Review package README and repo link

The Risk

When one backend serves multiple apps (e.g., a shared API behind App A, App B, and a dashboard), changing CORS origins, auth behavior, or rate limits for one app can break the others. You push a CORS fix for App A and App B's fetch calls start failing with opaque CORS errors. This is especially dangerous because the broken app shows no error in server logs - only the browser console reveals the CORS failure.

The Solution

Before changing any shared backend configuration: list all apps that depend on it (check CORS origins list, API monitor logs, cron jobs, MCP endpoints). Test the change against each app's endpoints. If possible, use environment variables so CORS origins and rate limits are configurable per deployment. When in doubt, add the new origin to the allow list rather than replacing the existing ones.

The Fix

# Before changing a shared backend:
# 1. List all consumers
grep -r "BACKEND_URL" ../*/  # find all apps calling this backend
# Check API monitor: which apps hit which endpoints?

# 2. Check CORS origin list covers all consumers
origins = os.getenv("CORS_ORIGINS", "").split(",")
# Verify: every frontend that calls this backend is in the list

# 3. Test each app after deploying changes
# CORS failures show in browser console, NOT server logs

# 4. Use env vars for flexibility (per-deployment config)
RATE_LIMIT = os.getenv("RATE_LIMIT", "30/minute")
# Different deployments can have different limits

The Risk

Unlike Vercel (auto-deploys on git push), self-hosted platforms like Coolify often require manual deployment triggers. After pushing a security fix, the old vulnerable code keeps running until you explicitly deploy. This gap can be minutes or hours - during which your fix exists in git but not in production.

The Solution

For security-critical changes: verify whether auto-deploy is enabled BEFORE pushing. If not, immediately trigger deployment after push (via Coolify API, dashboard, or webhook). After deployment, verify the new version is running - hit the /health endpoint, check container logs, or look for a version indicator. Don't assume pushing means deploying.

The Fix

# After pushing a security fix:

# 1. Check if auto-deploy is enabled
# Coolify: Settings > Auto Deploy toggle
# If OFF, trigger manually:
curl -X POST "https://coolify.example.com/api/v1/deploy" \\
  -H "Authorization: Bearer $COOLIFY_TOKEN" \\
  -d '{"uuid": "app-uuid"}'

# 2. Verify new version is running
curl https://app.example.com/health
# Check: response should reflect the fix

# 3. Check container logs for successful startup
docker logs <container> --tail 20

The Risk

After major refactors - consolidating endpoints, migrating auth systems, switching from direct API calls to a proxy - code paths that were once reachable may become dead. This seems harmless, but dead code with auth exemptions is a latent vulnerability. If someone later creates a route or endpoint that accidentally hits that old code path, the auth bypass activates silently. Real-world example: after consolidating 11 API endpoints into a single RPC endpoint with JWT auth, a Calendly webhook handler inside one of the old handlers still had an auth exemption (it used webhook signature verification instead of JWT). The old endpoint no longer existed, but the code was still there inside the handler function. If someone later re-created that endpoint path for any reason, the auth bypass would have been active.

The Solution

After any major architecture change, audit the codebase for: (1) Auth bypass patterns - search for code that skips JWT/auth verification for specific actions or paths, then verify those paths are still reachable and intentional. (2) Hardcoded URLs referencing old endpoint structure - webhook callback URLs, redirect URLs, API base URLs that point to deleted paths. (3) Conditional auth logic - if/else branches that grant different auth treatment based on action type or path. Remove unreachable branches entirely rather than leaving them as dead code.

The Fix

# After consolidating endpoints or changing auth flow:

# 1. Search for auth bypass patterns
grep -rn "skip.*auth\\|no.*auth\\|bypass\\|exempt\\|without.*verify" api/
grep -rn "action.*===.*webhook\\|action.*===.*public" api/

# 2. Search for hardcoded URLs to old endpoints
grep -rn "/api/old-endpoint\\|api/calendar\\|api/webhook" .

# 3. Search for conditional auth (different paths get different treatment)
grep -rn "if.*action.*===.*\\|switch.*action" api/
# Then verify each branch is still reachable

# 4. After cleanup, verify nothing broke:
npm run build  # frontend compiles
# Hit each endpoint to confirm auth still works

The Risk

The instinct during an attack is to immediately restart containers, redeploy, or change code. This destroys logs and evidence. But blindly preserving logs while data is being stolen is equally wrong. The correct response depends on what's happening - is there active damage right now, or are you investigating something that already happened?

The Solution

First, assess: is the attack ACTIVE (data being exfiltrated, records being deleted, resources being drained right now) or DISCOVERED (you found evidence of a past breach, probing, or vulnerability)? For active damage, stop the bleeding first - shut down the service or block at the firewall immediately. Logs are worthless if the attacker is still inside deleting data. For discovered incidents (post-breach investigation, reconnaissance detected in logs, vulnerability found), preserve evidence first - don't restart anything until you've saved the logs.

The Fix

ACTIVE ATTACK (data theft, deletion, resource drain):
1. KILL   - shut down the service or block at Cloudflare firewall
             (stop the damage NOW - logs are secondary)
2. DUMP   - save container logs, API monitor, CF analytics,
             pg_stat_activity (from the stopped state)
3. ASSESS - what was accessed, what was taken
4. HARDEN - fix the vulnerability before restarting

DISCOVERED INCIDENT (past breach, probing, vuln found):
1. STOP   - do NOT restart or redeploy (preserves logs)
2. DUMP   - container logs, API monitor, CF analytics,
             pg_stat_activity
3. BLOCK  - Cloudflare firewall rules per IP (faster than app-level)
4. HARDEN - fix the vulnerability, then deploy

The Risk

A secret committed to git - even briefly, even in a private repo - should be considered compromised. Bots that scrape GitHub for secrets operate within minutes. Simply deleting the file doesn't help because the secret remains in git history forever unless explicitly scrubbed.

The Solution

The moment you discover a leaked credential, generate a new one immediately - don't wait to investigate first. Update the new credential in all your environments (Vercel, Coolify, local), then revoke the old one from the provider's dashboard. Check the provider's access logs to see if anyone used the leaked credential while it was exposed. If the repo might go public, scrub the secret from git history too.

The Fix

1. Rotate the credential IMMEDIATELY (generate new)
2. Update env vars in all environments
   (Vercel, Coolify, local)
3. Revoke the old credential from provider dashboard
4. Check git history for other exposures:
   git log --all --oneline -- "**/.*env*"
5. Audit provider access logs for unauthorized usage
   during the exposure window

# Scrub from git history if repo may go public:
# Use BFG Repo-Cleaner or git filter-repo

The Risk

Most teams only rotate credentials after a breach. But secrets accumulate risk over time - they get shared in Slack, copied to local machines, cached in CI pipelines, and stored in browser password managers. The longer a secret lives, the more places it exists and the more likely it has leaked somewhere you don't know about.

The Solution

Have a documented plan for how to rotate each credential your app depends on: database passwords, API keys, OAuth client secrets, signing keys. Know the steps BEFORE you need them - during a breach is the wrong time to figure out the process. Ideally, rotate proactively on a schedule (quarterly for high-value secrets). At minimum, know which environment variables need updating when a key changes, and test that your app handles the rotation without downtime.

The Fix

# Secret rotation checklist per credential:
# 1. Where is it stored? (Vercel, Coolify, .env, CI)
# 2. What breaks if I change it? (which services)
# 3. Can I rotate without downtime?
#    (some services support two active keys)
# 4. How do I generate a new one?
#    (provider dashboard, CLI, API)
# 5. What environments need updating?
#    (prod, staging, local, CI)

# Practical steps:
# - Document rotation procedure for each key
# - Keep a list: which secrets exist, where, last rotated
# - After any team member leaves: rotate shared secrets
# - After any security incident: rotate everything

The Risk

When an incident happens, your first instinct is to SSH into the affected container and grep logs. With 30+ backends, this takes hours - and by the time you find the relevant entries, the attacker may have moved to another service. Container logs are also lost on redeploy. If you don't have centralized logging set up BEFORE the incident, you're doing forensics blind.

The Solution

Your centralized API logging dashboard (item 2.14) is the first place to go during any incident. Filter by the suspicious IP across ALL backends to see the full attack timeline - what they probed first, which endpoints they hit, what payloads they sent. The 30-day window of request bodies and client IPs gives you the raw evidence. Cross-reference with Cloudflare analytics (which shows blocked requests the backend never saw) and pg_stat_activity (for active database queries). This is why centralized logging must be set up before you need it - during an incident is too late.

The Fix

# Incident investigation sequence:

# 1. Centralized API dashboard - filter by suspicious IP
#    See: all endpoints hit, payloads sent, status codes, timing
#    Cross-backend: did this IP probe other services?

# 2. Cloudflare analytics - what was BLOCKED
#    Dashboard > Analytics > filter by IP
#    Shows requests that never reached your backend
#    (WAF blocks, rate limit blocks, challenge failures)

# 3. Database activity - active/recent queries
#    SELECT * FROM pg_stat_activity WHERE state = 'active';
#    Check for: long-running queries, unusual query patterns

# 4. Container logs - only if centralized logs are incomplete
#    docker logs <container> --since 2h | grep <ip>
#    WARNING: lost on redeploy, this is your last resort

# 5. Timeline reconstruction
#    Combine all sources into a single timeline:
#    IP → first probe → escalation → data access → blocking

The Risk

fastapi-mcp makes internal HTTP calls to your FastAPI endpoints. Without configuration, ALL MCP queries appear to come from the server's own IP. This means per-IP rate limiting and concurrency limits treat every MCP user as the same person - either everyone is rate-limited or nobody is.

The Solution

Configure the MCP server to forward the original client's IP address when it makes internal calls to your API. By default, all MCP requests appear to come from localhost, so your rate limiting can't tell users apart. Pass through headers like cf-connecting-ip and x-forwarded-for. CRITICAL: the base_url MUST be localhost - if you use the external domain, the request goes through Cloudflare on the way back in, which overwrites cf-connecting-ip with your server's own IP, destroying the real client IP.

The Fix

import httpx
from fastapi_mcp import FastApiMCP

mcp = FastApiMCP(
    app,
    headers=["authorization", "cf-connecting-ip",
             "x-forwarded-for", "x-real-ip"],
    http_client=httpx.AsyncClient(
        # MUST be localhost - external URL goes through Cloudflare
        # and overwrites cf-connecting-ip with server's own IP
        base_url="http://localhost:8000",
        timeout=60.0,
    ),
)

The Risk

A single MCP endpoint forces a choice: open to all (insecure) or locked down (unusable for demos). Running two endpoints side by side lets you serve both use cases, with all security layers (rate limiting, SQL validation, concurrency) active on both.

The Solution

Run two separate MCP endpoints: one open (no login required) for demos and testing, and one secured with authentication (OAuth + JWT + email whitelist) for production use. Both endpoints still get all the other protections - rate limiting, SQL validation, concurrency limits. The difference is just who's allowed to connect.

The Fix

# Two MCP endpoints:
/mcp        - open, no auth (demo/testing)
/mcp-secure - Auth0 OAuth + JWT + email whitelist

# Both get: rate limiting, SQL validation, concurrency
# /mcp-secure adds: identity verification via OAuth

The Risk

fastapi-mcp 0.4.0 uses SSE transport. Some newer MCP clients (like Claude Code) use Streamable HTTP, which sends a POST to /mcp - and your SSE endpoint returns 405 Method Not Allowed. This silently breaks connectivity for newer clients.

The Solution

Be aware that the MCP protocol has two transport methods - SSE (older) and Streamable HTTP (newer). If your MCP library only supports SSE, newer clients that expect Streamable HTTP will get errors when connecting. Keep your MCP library updated and watch for releases that add support for the newer transport method.

The Fix

# Monitor fastapi-mcp releases for Streamable HTTP support
# Current workaround: clients must use SSE transport
# Future: upgrade fastapi-mcp when POST transport is supported

The Risk

Your secured MCP endpoint validates JWT tokens on every connection. Without rate limiting on failed attempts, an attacker can send thousands of fake tokens probing for valid ones, timing differences, or error message leaks. Your application-level rate limits (SlowAPI) protect query endpoints but not the SSE connection handshake where JWT validation happens.

The Solution

Track failed auth attempts per IP in memory. After a configurable threshold, block that IP from further attempts with a 429 response. Choose thresholds based on your use case - a public API with many users might allow 20 failures per hour, while a private internal tool might allow only 3 failures with a 24-hour block. This stops brute-force probing without affecting legitimate users who authenticate successfully on first try.

The Fix

# In-memory failed-auth tracker
_auth_failures: dict[str, list[float]] = {}

# Tune these to your use case:
#   Public API with many users:  AUTH_FAIL_MAX=20, WINDOW=3600 (1hr)
#   Internal tool, few users:    AUTH_FAIL_MAX=3,  WINDOW=86400 (24hr)
#   General-purpose default:     AUTH_FAIL_MAX=5,  WINDOW=86400 (24hr)
AUTH_FAIL_MAX = int(os.getenv("AUTH_FAIL_MAX", "5"))
AUTH_FAIL_WINDOW = int(os.getenv("AUTH_FAIL_WINDOW", "86400"))
AUTH_FAIL_MAX_IPS = 1000  # cap tracked IPs to bound memory

def _is_auth_blocked(ip: str) -> bool:
    if ip not in _auth_failures:
        return False
    now = time.time()
    cutoff = now - AUTH_FAIL_WINDOW
    # Prune expired entries
    _auth_failures[ip] = [t for t in _auth_failures[ip] if t > cutoff]
    if not _auth_failures[ip]:
        del _auth_failures[ip]
        return False
    return len(_auth_failures[ip]) >= AUTH_FAIL_MAX

def _record_auth_failure(ip: str):
    now = time.time()
    _auth_failures.setdefault(ip, []).append(now)
    # Periodic cleanup: evict expired IPs when dict grows too large
    if len(_auth_failures) > AUTH_FAIL_MAX_IPS:
        cutoff = now - AUTH_FAIL_WINDOW
        expired = [k for k, v in _auth_failures.items()
                   if not v or v[-1] < cutoff]
        for k in expired:
            del _auth_failures[k]

async def verify_oauth_token(request: Request):
    client_ip = get_client_ip(request)
    if _is_auth_blocked(client_ip):
        raise HTTPException(429, "Too many failed attempts")
    try:
        # ... validate JWT ...
        pass
    except JWTError:
        _record_auth_failure(client_ip)
        raise HTTPException(401, "Invalid token")

The Risk

When you spin up a new server, password login is often enabled by default. Bots start scanning for SSH access within hours. If password login is enabled, they will brute-force it - even strong passwords are vulnerable to sustained automated attacks with millions of combinations.

The Solution

Disable password login entirely and only allow SSH key authentication. SSH keys are effectively impossible to guess (they are thousands of characters long). Once configured, anyone trying to log in with a password is rejected instantly - they never get a chance to guess. This is a one-time setup during server provisioning.

The Fix

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

# Apply changes
sudo systemctl restart sshd

The Risk

Even with SSH key-only authentication, bots will keep trying to connect. Each failed attempt consumes CPU for the handshake rejection. Thousands of simultaneous attempts can spike CPU to 100% and crash your server. This happened in production - server went down from the sheer volume of rejected connections.

The Solution

Install fail2ban, which monitors your SSH log for failed login attempts. After a set number of failures (say 5) from the same IP within an hour, it bans that IP at the firewall level for 24 hours. The banned IP's connections are dropped before they even reach SSH, so there is zero CPU cost. Real-world results: 150+ IPs banned at any time, 6,000+ blocked attempts per week.

The Fix

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
findtime = 3600     # 1-hour observation window
bantime = 86400     # 24-hour ban

The Risk

By default, many ports may be open on your server. Each open port is a potential entry point for attackers. Database ports (5432 for Postgres, 3306 for MySQL), admin panels, and debug servers should never be reachable from the internet.

The Solution

Only three ports need to be open: 22 (SSH for server management), 80 (HTTP), and 443 (HTTPS). Close everything else. Configure the firewall at the cloud provider level (Hetzner Firewall, OCI Security Lists) so traffic is dropped before it reaches your server - zero CPU cost. Services that need to talk to each other should use Docker internal networking, not exposed ports.

The Fix

# OS-level firewall (ufw)
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Also configure at cloud provider level
# (Hetzner Firewall / OCI Security Lists)

The Risk

When you first set up a server, you're logged in as root with full control over everything. If an application vulnerability is exploited while running as root, the attacker owns your entire system - every file, every service, every secret on the machine.

The Solution

Create a dedicated non-root user with sudo access and run all your applications under that user. This limits the damage if something goes wrong - an attacker can only access what that user has permission to, not the entire system. Docker, Coolify, and your applications should all run under this restricted user, not root.

The Fix

# Create a deploy user with sudo access
adduser deploy
usermod -aG sudo deploy

# Disable root password login
passwd -l root

# Run apps as this user, not root

The Risk

Every Nixpacks/Docker build creates a 1-1.5GB image, and old images are never cleaned up automatically. On a typical VPS with 75GB disk, you can fill the entire disk in a single batch deployment session (40+ apps). When the disk fills up, everything stops - containers can't write logs, databases can't write WAL files, and new deploys fail silently.

The Solution

Run docker image prune -f between deployments to remove unused images. For batch redeploy sessions (like updating all apps at once), prune after every 5-10 deploys. Set up a cron job or deploy hook to prune weekly. Monitor disk usage - if your server has less than 20% disk free after a deploy, prune immediately.

The Fix

# After each deploy or between batch deploys
docker image prune -f

# Check disk usage
df -h /

# Nuclear option: remove ALL unused images, volumes, networks
docker system prune -af --volumes

# Cron job: weekly cleanup (add to deploy user's crontab)
0 3 * * 0 docker image prune -f >> /var/log/docker-prune.log 2>&1

The Risk

Without clear rules for when to require authentication, developers either add friction to apps that should be frictionless (killing adoption of public demos) or skip auth on apps that handle sensitive data (creating a wide-open door). Both are expensive mistakes - one costs users, the other costs security.

The Solution

OAuth is mandatory when your app handles private or sensitive data, when it's for internal use or a small specific audience, when you need per-user rate limiting or audit trails, or when you need role-based access control (who can see what). It's optional for public demo apps where frictionless access drives adoption. Even for public apps, OAuth gives you benefits: user behavior monitoring, a contact list for marketing, and abuse tracking tied to real identities. The trade-off is real friction - login walls reduce casual usage. For public apps, it's your call. For private apps, there is no choice.

The Fix

# OAuth is MANDATORY when:
# - App handles private/sensitive data
# - Internal tools for specific team/audience
# - Per-user rate limits needed
# - Role-based access control required
#   (e.g., only certain users query certain DBs)
# - Audit trail of who did what is required

# OAuth is OPTIONAL (developer choice) when:
# - Public demo app - frictionless access matters
# - Open data - nothing sensitive exposed
# - Portfolio/showcase apps

# Even for public apps, OAuth gives you:
# - User behavior analytics
# - Marketing: email list of users
# - Abuse tracking: ban by identity, not just IP
# - Rate limiting per user (more accurate than IP)

# If public app + optional OAuth:
# Rely on the REST of the hardening stack
# (rate limits, SQL validation, CORS, etc.)

The Risk

Frontend authentication is just a UI convenience - it tells the browser who is logged in. It is NOT security. Anyone with curl, Postman, or browser DevTools can call your API directly, bypassing all frontend auth checks. If your backend doesn't independently verify the token, your API is effectively public.

The Solution

Your backend must verify the JWT on every single request that needs authentication. Extract the Bearer token from the Authorization header, verify its cryptographic signature against the OAuth provider's public keys (JWKS endpoint), and check the audience, issuer, and expiry claims. If any of these checks fail, reject the request with a 401. The backend should never trust the frontend - it should trust only the cryptographic proof in the token.

The Fix

# FastAPI - verify Auth0 JWT on every request
from jose import jwt as jose_jwt, JWTError
import httpx

async def verify_token(request: Request):
    auth = request.headers.get("Authorization", "")
    if not auth.startswith("Bearer "):
        raise HTTPException(401, "Missing bearer token")
    token = auth.split(" ", 1)[1]

    # Fetch provider's public keys (cache in production)
    jwks_url = f"https://{AUTH0_DOMAIN}/.well-known/jwks.json"
    async with httpx.AsyncClient() as client:
        jwks = (await client.get(jwks_url)).json()

    try:
        payload = jose_jwt.decode(
            token, jwks,
            algorithms=["RS256"],
            audience=AUTH0_AUDIENCE,
            issuer=f"https://{AUTH0_DOMAIN}/",
        )
        return payload  # contains user info (sub, email)
    except JWTError:
        raise HTTPException(401, "Invalid or expired token")

# Apply to protected endpoints:
@app.get("/api/data", dependencies=[Depends(verify_token)])

The Risk

Any API key in your frontend JavaScript is visible to everyone. Browser DevTools, View Source, or a simple network tab inspection reveals keys embedded in bundled code or sent in fetch headers. Once someone has your key, they can use your API quota, access your data, or impersonate your app - and you'll pay the bill.

The Solution

API keys must live server-side only - in environment variables on your hosting platform (Vercel, Coolify). Use a serverless proxy pattern: your frontend calls a Vercel API route on your own domain, and that server-side function adds the API key before forwarding the request to the actual backend. The key never reaches the browser. This is the same pattern for any secret: database URLs, signing keys, OAuth client secrets.

The Fix

// Frontend - calls own domain, no keys visible
const res = await fetch("/api/query", {
    method: "POST",
    body: JSON.stringify({ sql: query }),
});

// Vercel API route (api/query.ts) - adds key server-side
export default async function handler(req, res) {
    const API_KEY = process.env.BACKEND_API_KEY; // server-side only
    const response = await fetch(BACKEND_URL + "/query", {
        method: "POST",
        headers: {
            "Authorization": \

The Risk

Authentication tells you WHO someone is. Without authorization, every authenticated user can do everything - query any database, delete any file, access any admin panel. A logged-in user with no role restrictions has the same power as an admin.

The Solution

After verifying identity, check what each user is allowed to do. This can be as simple as an admin vs user role, or as granular as per-file or per-table permissions. Store roles in your auth provider (Auth0 app_metadata, Clerk publicMetadata) or your own database. Check the role on every request - not just in the UI. The backend must enforce roles independently, because frontend role checks are just UI cosmetics.

The Fix

# Simple RBAC pattern in FastAPI
async def require_admin(request: Request):
    payload = await verify_token(request)  # from 9.2
    role = payload.get("app_metadata", {}).get("role", "user")
    if role != "admin":
        raise HTTPException(403, "Admin access required")

# Granular: file-level access control
async def check_file_access(user_email: str, filename: str):
    # Query your DB: does this user have access to this file?
    allowed_files = await get_user_files(user_email)
    if filename not in allowed_files:
        raise HTTPException(403, "Access denied to this file")

# Apply to endpoints:
@app.delete("/api/files/{name}", dependencies=[Depends(require_admin)])
@app.get("/api/query/{file}", dependencies=[Depends(verify_token)])
async def query_file(file: str, request: Request):
    user = request.state.user  # set by verify_token
    await check_file_access(user["email"], file)

The Risk

MCP servers give AI clients direct access to your databases and tools. An open MCP server means any AI client on the internet can query your data. For demo servers with public data, this may be acceptable (with other hardening). But for servers with private data, this is a direct path to data exfiltration.

The Solution

fastapi-mcp supports OAuth out of the box via its AuthConfig. The practical pattern is to run two MCP endpoints: an open one at /mcp for public demos (protected by rate limiting, SQL validation, and other hardening), and a secured one at /mcp-secure that requires Auth0 JWT authentication. The secured endpoint verifies the token on every request and can restrict access by user identity. For team use, combine this with role-based access to control which team members can query which databases.

The Fix

from fastapi_mcp import FastApiMCP, AuthConfig
from fastapi import Depends

# Open MCP - for public demos (relies on other hardening)
mcp_open = FastApiMCP(app, name="MCP (Open)", ...)
mcp_open.mount()  # /mcp

# Secured MCP - requires Auth0 OAuth
mcp_secure = FastApiMCP(
    app,
    name="MCP (Secured)",
    auth_config=AuthConfig(
        issuer=f"https://{AUTH0_DOMAIN}/",
        authorize_url=f"https://{AUTH0_DOMAIN}/authorize",
        audience=AUTH0_AUDIENCE,
        client_id=AUTH0_CLIENT_ID,
        client_secret=AUTH0_CLIENT_SECRET,
        dependencies=[Depends(verify_oauth_token)],
        setup_proxies=True,
    ),
)
mcp_secure.mount(mount_path="/mcp-secure")

The Risk

Some operations need to bypass the normal API flow - like large file uploads that exceed your serverless platform's payload limit (Vercel caps at 4.5MB). If you issue a long-lived or reusable token for these operations, a leaked token can be replayed indefinitely. If you skip tokens entirely and let the frontend call the backend directly, you expose your API key.

The Solution

Generate short-lived, single-use tokens server-side for sensitive operations. The frontend requests a token through your serverless proxy (which has the API key), receives a random token, and uses it to call the backend directly for that one operation. The backend verifies the token exists, hasn't expired, and then deletes it after use. The token works once and is gone - even if intercepted, it cannot be replayed.

The Fix

import secrets, time

UPLOAD_TOKENS = {}  # In production, use Redis

@app.post("/upload-token")  # called via serverless proxy
async def create_upload_token(request: Request):
    verify_api_key(request)  # only proxy has the key
    token = secrets.token_urlsafe(32)
    UPLOAD_TOKENS[token] = {
        "created": time.time(),
        "expires_at": time.time() + 600,  # 10 min
    }
    return {"token": token}

@app.post("/upload-direct/{token}")  # frontend calls directly
async def upload_direct(token: str, file: UploadFile):
    if token not in UPLOAD_TOKENS:
        raise HTTPException(401, "Invalid or expired token")
    if time.time() > UPLOAD_TOKENS[token]["expires_at"]:
        del UPLOAD_TOKENS[token]
        raise HTTPException(401, "Token expired")
    # Process upload...
    del UPLOAD_TOKENS[token]  # consume - one-time use
    return {"status": "uploaded"}

The Risk

If uploaded files are served at predictable URLs (like /files/report.csv), anyone who guesses or discovers the filename can download it. Directory listing attacks, URL enumeration, and shared links that never expire are all common vectors for unauthorized file access.

The Solution

Generate cryptographically signed URLs that embed the filename and an expiry timestamp. The signature prevents tampering - changing the filename or extending the expiry invalidates the URL. Set a reasonable expiry (hours to days depending on use case) so shared links don't work forever. When a user requests a file, generate a fresh signed URL and redirect them to it.

The Fix

from itsdangerous import URLSafeTimedSerializer

SIGNING_SECRET = os.getenv("SIGNING_SECRET")
url_signer = URLSafeTimedSerializer(SIGNING_SECRET)

def generate_signed_url(filename: str, base_url: str) -> str:
    token = url_signer.dumps({"file": filename})
    return f"{base_url}/secure-download/{token}"

@app.get("/secure-download/{token}")
async def secure_download(token: str):
    try:
        data = url_signer.loads(token, max_age=172800)  # 48h
    except Exception:
        raise HTTPException(403, "Invalid or expired link")

    filepath = UPLOAD_DIR / data["file"]
    if not filepath.exists():
        raise HTTPException(404, "File not found")

    return FileResponse(
        filepath,
        headers={
            "Content-Disposition": f'attachment; filename="{data["file"]}"',
            "X-Content-Type-Options": "nosniff",
        },
    )

The Risk

Picking the wrong auth provider costs you twice - once during setup and again when you migrate. Some providers charge for basic features (Clerk charges $25/mo for email allowlists). Some have great developer experience but less flexibility. Some are rock-solid but take longer to wire up. The wrong choice can lock you into a provider that doesn't fit your needs or charge you for features that others offer free.

The Solution

Auth0 is the long-term standard - 12+ years old, owned by Okta, most features, free allowlist via Actions, HIPAA-capable. It takes longer to set up (more config spread across Dashboard, Actions, APIs) but it's the most flexible and the most likely to exist in 10 years. Clerk is the fastest to set up - AI coders wire it up in minutes, excellent React components, but allowlists require the paid Pro plan. Supabase Auth is good if you're already on Supabase (50K free MAU, allowlist via RLS). Neon Auth is new (built on Better Auth), interesting for branchable auth in dev workflows, but still Beta. For quick temporary lockdowns, Clerk works fast. For everything else, standardize on Auth0.

The Fix

# Decision framework:

# Auth0 - default choice for production apps
# + Free allowlist (via Actions)
# + 7,500-25,000 free MAU
# + Most features, extensive customization
# + HIPAA, enterprise compliance
# + 12+ years stable (owned by Okta)
# - More wiring (15-30 min vs 5 min for Clerk)
# - Config spread across Dashboard/Actions/APIs
# - AI coders need 2-4 iterations to get it right

# Clerk - fastest setup, great DX
# + AI coders set it up in minutes
# + Excellent pre-built React components
# + 10,000 free MAU
# - Allowlist requires Pro ($25/mo)
# - Less customization than Auth0
# Good for: quick lockdowns, prototypes

# Supabase Auth - if already on Supabase
# + 50,000 free MAU (most generous)
# + Allowlist via Row Level Security
# + Integrated with Supabase DB
# - Tied to Supabase ecosystem

# Neon Auth - watch but wait
# + Branchable auth (auth branches with DB)
# + Built on Better Auth (open source)
# - Still in Beta
# - No allowlist feature yet
# - Tied to Neon ecosystem

The Risk

WARNING: This item describes a FRONTEND-ONLY access gate pattern. It is cosmetic and can be easily bypassed by anyone who opens browser DevTools and fakes the API response (e.g., changing a 403 into a 200 with {granted: true}). The frontend JavaScript trusts whatever the fetch() call returns - an attacker simply intercepts the response in the Network tab. This provides zero real security against anyone with basic browser knowledge. The recommended approach is to enforce the access gate server-side using Routing Middleware - see item 9.11 (Server-Side Access Gate via Routing Middleware). That approach checks the gate at the infrastructure level before your API code even runs. No amount of DevTools trickery can get around it. If you only implement one, implement 9.11. If you choose not to go with the server-side approach, or if you want a lightweight cosmetic layer on top of it, the frontend pattern below still has some value. It hides the login form from casual visitors, makes your app look like a normal Google login page, and adds a psychological speed bump. It deters unsophisticated visitors who don't know about DevTools - but it stops nobody who does. Think of it as a curtain, not a wall.

The Solution

Add a code barrier before the OAuth login. The user sees a text input asking for an access code. They type the code and click the button. If the code is correct, they're forwarded to the normal OAuth login (Google, etc.). If the code is wrong, they're immediately blocked - no second chance, no "try again" message, just a permanent block screen. The clever part: the button looks like a normal "Sign in with Google" button, so casual visitors think it's just a regular Google login with a password field. They don't realize the access code is checked first. This means even if someone screenshots or shares your login page, it looks like a standard Google login - not a secret access gate. How the flow works: User enters code → frontend sends code to your serverless function → server checks code using constant-time comparison (prevents timing attacks where an attacker can guess characters based on how fast the server responds) → if correct, returns "granted" and frontend triggers the real OAuth redirect → if wrong, server blocks the IP in Redis (see item 1.21) and frontend shows a permanent block screen. Combine this with Turnstile (item 1.20) so bots can't even attempt the code, and IP blocking (item 1.21) so humans get one shot. The result: an attacker needs to (1) be a real browser to pass Turnstile, (2) know the access code on the first try, (3) have an allowed Google account, and (4) pass Auth0's email allowlist - all without any indication of what's expected at each step.

The Fix

// Frontend - looks like a normal Google login with a code field
const handleAuthenticate = async () => {
  // 1. Send code + Turnstile token to server
  const resp = await fetch('/api/access-gate', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      code: accessCode.trim(),
      turnstileToken: turnstileToken
    })
  });
  const data = await resp.json();

  if (data.granted) {
    // 2. Code correct - NOW trigger real OAuth
    loginWithRedirect();
  } else {
    // 3. Wrong code - show block screen
    setBlocked(true);
  }
};

// Server (Vercel serverless function)
const ACCESS_CODE = process.env.ACCESS_GATE_CODE;
const TURNSTILE_SECRET = process.env.TURNSTILE_SECRET_KEY;

export default async function handler(req, res) {
  const clientIp = getClientIp(req); // cf-connecting-ip

  // Step 1: Check if already blocked (see item 1.21)
  const blocked = await redis.get(\

The Risk

ADDITIONAL HARDENING - MFA is strongly recommended for admin tools and apps with sensitive data, but it's an extra step that adds friction to every login. For public-facing apps with many users, consider making it optional or risk-based (only trigger MFA for suspicious logins). For private dashboards and admin panels, MFA is one of the most effective security measures you can add - it stops an attacker even if they have your password. Passwords and access codes can be stolen - through phishing, shoulder surfing, keyloggers, or data breaches. If someone gets hold of your Google account password (through a phishing email, a leaked database, or someone watching you type), they can log into your app as you. OAuth helps because you're relying on Google's security, but if your Google account itself is compromised, every app that uses "Sign in with Google" is wide open. A password alone - no matter how strong - is a single point of failure.

The Solution

Add a second factor: something you physically have, not just something you know. After signing in with Google, Auth0 asks for a 6-digit code from an authenticator app on your phone (Google Authenticator, Authy, etc.). This code changes every 30 seconds and can only be generated by the app on your physical device. Even if an attacker has your Google password, they can't log in without your phone. The setup is a one-time process: the first time you log in after MFA is enabled, you see a QR code on screen. You open Google Authenticator on your phone, tap the "+" button, scan the QR code with your camera - done. From that point on, the app shows a new 6-digit code every 30 seconds. Nobody else can generate these codes unless they scanned that same QR code at that exact moment (and the QR code is only shown once, behind your Google login, so an attacker would need access to your Google account AND be looking at your screen during setup). The best part: if you're using Auth0, this requires zero code changes in your app. Auth0 handles the entire MFA flow - the QR code screen, the code verification, the recovery codes - all on their hosted login page. You just enable it in Auth0's settings or via an Action, and it works. With allowRememberBrowser enabled, Auth0 remembers your browser for 30 days after a successful MFA verification. So you're not typing a 6-digit code every single login - just on new browsers, new devices, or after 30 days. Minimal friction for you, maximum friction for attackers.

The Fix

// OPTION 1: Enable MFA for a specific app via Auth0 Action
// (recommended - doesn't affect your other apps on the same tenant)

// In your existing post-login Action, add one line:
exports.onExecutePostLogin = async (event, api) => {
  const clientId = event.client.client_id;

  // Only require MFA for your admin dashboard
  if (clientId === 'YOUR_APP_CLIENT_ID') {
    // Require MFA - shows Google Authenticator prompt
    // allowRememberBrowser: remembers this browser for 30 days
    api.multifactor.enable('any', { allowRememberBrowser: true });
  }
};

// OPTION 2: Enable MFA for ALL apps on the tenant
// Auth0 Dashboard > Security > Multi-factor Auth
// Toggle "One-time Password" to ON
// Set policy to "Always"
// (simpler but applies to every app on this tenant)

// PREREQUISITE: Enable the OTP factor on your Auth0 tenant
// Via Auth0 Management API:
// PUT /api/v2/guardian/factors/otp  {"enabled": true}
// PUT /api/v2/guardian/factors/recovery-code  {"enabled": true}

// Or via Auth0 CLI:
// auth0 api put "guardian/factors/otp" --data '{"enabled": true}'
// auth0 api put "guardian/factors/recovery-code" --data '{"enabled": true}'

// FIRST-TIME USER EXPERIENCE:
// 1. User logs in normally (Google, email, etc.)
// 2. Auth0 shows a QR code on screen
// 3. User opens Google Authenticator > tap "+" > "Scan QR code"
// 4. Points phone camera at QR code - app starts showing 6-digit codes
// 5. User types current 6-digit code to confirm setup
// 6. Auth0 shows recovery codes (SAVE THESE - needed if phone is lost)
// 7. Done - future logins ask for the 6-digit code after OAuth

// RECOVERY: If user loses their phone
// Admin can reset MFA via Auth0 Dashboard > User Management > user > MFA
// Or via API: DELETE /api/v2/guardian/enrollments/{enrollment_id}

The Risk

A frontend-only access gate (item 9.9) is cosmetic - anyone who opens DevTools can fake the API response and bypass it. The frontend JavaScript trusts whatever fetch() returns, so an attacker intercepts the response in the Network tab, changes the status to 200, and they're in. This was confirmed during penetration testing: the tester bypassed the frontend gate in under a minute using Chrome DevTools response overrides. The real security gap: even after bypassing the frontend gate, the attacker reaches your actual API endpoints. If those endpoints rely on JWT auth alone, the attacker still can't read data - but they can probe endpoints, discover your API surface, and test for misconfigurations. A server-side gate adds a layer that runs before your API code even executes, blocking unauthorized requests at the infrastructure level. Real-world learning: during a security audit, a frontend-only gate was bypassed trivially. The fix was adding server-side enforcement via Vercel Routing Middleware - a middleware layer that intercepts every request before it reaches serverless functions. After deployment, the same pen tester confirmed they could no longer reach any API endpoint without passing the gate.

The Solution

Use Vercel Routing Middleware (middleware.ts at the project root) to enforce the access gate server-side. This middleware runs on Vercel's Edge network before every request reaches your serverless functions. It checks Redis for two keys per client IP: 1. gate:blocked:{ip} - if present, return 403 immediately (permanent block from wrong access code) 2. gate:passed:{ip} - if NOT present, return 403 (hasn't passed the access gate yet) Only if the IP has passed the gate AND is not blocked does the request continue to your serverless function. This cannot be bypassed from the browser because the middleware runs at Vercel's infrastructure level - the request never reaches your JavaScript code unless the IP is pre-authorized in Redis. Key design decisions: - Exempt the gate endpoint itself (/api/access-gate) so users can submit their code - Exempt cron job requests (valid CRON_SECRET in Authorization header) - If your app receives webhooks, exempt only specific webhook paths (see note below) - Use Upstash Redis REST API directly (no SDK) for Edge compatibility - Extract real client IP from cf-connecting-ip header when behind Cloudflare (not x-forwarded-for, which contains the Cloudflare proxy IP) - Fail open if Redis is unreachable (let the request through to the JWT auth layer rather than locking everyone out) The middleware does NOT count toward Vercel's 12-serverless-function limit on the Hobby plan - it runs on the Edge runtime, separate from your serverless functions. Combined with the frontend gate (item 9.9), this creates defense-in-depth: frontend gate handles UX (hides login, shows block screen, deters casual visitors), server-side gate handles security (blocks unauthorized API access at the infrastructure level).

The Fix

// middleware.ts - at project root (not in /api/)
// Vercel Routing Middleware - runs before every request
import { next } from '@vercel/functions'
import type { RequestContext } from '@vercel/functions'

const KV_REST_API_URL = process.env.KV_REST_API_URL || ''
const KV_REST_API_TOKEN = process.env.KV_REST_API_TOKEN || ''
const CRON_SECRET = process.env.CRON_SECRET || ''

// Upstash REST API (Edge-compatible, no SDK needed)
async function redisGet(key: string): Promise<string | null> {
  if (!KV_REST_API_URL || !KV_REST_API_TOKEN) return null
  try {
    const resp = await fetch(
      \