CSRF Protection & Security Headers: The Missing Layer in AI-Built Apps

Quick answer: Review CSRF defenses separately from browser security headers. For cookie-authenticated actions, test the application’s token or origin checks and cookie settings. Response policies such as CSP, HSTS, and framing restrictions provide additional browser protections, but their presence does not establish that every attack is blocked.

By Daniel A · Kraftwire Software

Review browser response policies including Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Choose values for your application and test the deployed responses. These headers serve different purposes; they do not replace application-specific CSRF defenses for actions that use ambient browser credentials.

Inspect the deployed configuration as well as the source. Headers may be set by the application, framework, reverse proxy, or hosting platform.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

Investigate individual findings and their check definitions before attributing a cause or interpreting the aggregate category.

What Are Security Headers?

Security response headers let a server specify browser policies for resources, connections, framing, and other behavior. Their protection depends on the directives and browser support. They complement safe output handling and access controls; simply sending a header does not block every related attack.

Review the deployed responses as well as files such as App.tsx and the database schema. A component’s behavior does not show which headers the host sends.

The average security score across the 119 live sites SimplyScan has scanned is 86 out of 100.

Review generated code and deployed configuration directly, and test application-specific behavior alongside the supported automated checks. Inspect deployed security headers and test the relevant browser protections. See application security audit checklist.

Check the Deployed Configuration

Inspect the configuration mechanism used by your deployment, such as vercel.json or next.config.js where supported. Development and production settings can differ; inspect the actual response instead of assuming a source edit changed the deployed policy.

Inspect browser protections and separately review architecture risks, including data access and server-side authorization. A header check does not establish that those controls are correct.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one medium-severity architecture issue, such as a library with a known vulnerability or no rate limiting.

Review hardening separately using a saas security guide; these architecture figures do not identify AI generation as a cause.

The Essential Security Header Checklist

1. Content-Security-Policy (CSP)

CSP can restrict script execution and resource loading. It complements context-appropriate encoding and HTML sanitization. The sample below needs adaptation to your required resources; it is not a complete policy for every app.

What to check: Review the script sources and execution modes the policy allows. For browser API calls to Supabase or Firebase, configure the required endpoints in connect-src. That directive covers requests including fetch and XMLHttpRequest, but it does not cover every way data can leave a page. Use a CSP generator to draft a policy, then test it.

2. Strict-Transport-Security (HSTS)

Once a browser has a valid HSTS policy for the host, it upgrades applicable HTTP requests to HTTPS. It tells the browser that for a specified period, it should never attempt to connect via insecure HTTP. According to MDN, the HSTS header "informs browsers that the site should only be accessed using HTTPS."

What to check: HSTS reduces HTTP downgrade exposure once the browser knows the policy. An entry shipped in a browser’s preload list can cover the initial connection; the preload directive alone does not enroll the host. Confirm HTTPS support for affected subdomains before using the sample. The SSL checker reports HSTS and selected TLS observations.

3. X-Frame-Options

This header indicates "whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>," according to MDN documentation.

What to check: The shown value blocks framing in supporting browsers. CSP frame-ancestors can also control framing, so a missing X-Frame-Options header alone does not establish clickjacking vulnerability. Choose a policy compatible with intended embeds and test it. See the security audit checklist.

4. X-Content-Type-Options

This prevents the browser from "sniffing" the MIME type of a file. MDN defines it as a marker to ensure "MIME types advertised in the Content-Type headers should be followed and not be changed."

What to check: Serve the intended Content-Type and use nosniff to restrict MIME reinterpretation in supported contexts, including script and stylesheet loading. This does not make arbitrary uploads safe; also restrict file types and control how uploaded content is served.

5. Referrer-Policy

Controls information sent in the Referer header on requests, including navigation and resource loading.

The shown policy sends the origin rather than the full path on cross-origin requests that do not downgrade security. It omits the referrer on an HTTPS-to-HTTP downgrade and allows the full URL on same-origin requests. Avoid placing secrets in URLs in the first place.

6. Permissions-Policy

Restricts the use of browser features like the camera, microphone, or geolocation.

Why it matters: It reduces the attack surface. A restrictive Permissions-Policy can disable camera access in supporting browsers; it does not fix the underlying XSS flaw. This follows the principle of least privilege at the browser level, a key part of vibe coding guardrails.

Understanding and Fixing CSRF

CSRF attempts to make a browser perform an unwanted action using credentials it attaches automatically. Whether the request carries a session cookie depends on the cookie settings and request context. Test state-changing endpoints for an appropriate token or origin-validation defense rather than assuming a valid session proves user intent.

CSRF protection depends on the application’s authentication and request flow. The aggregate scan figures do not measure how often it is missing or attribute omissions to a development tool.

How to Implement CSRF Protection

SameSite Cookie Attribute

Set session-cookie attributes explicitly. SameSite=Lax and SameSite=Strict restrict cross-site cookie sending in supporting browsers, but they have different navigation behavior. Same-site is not the same as same-origin, and state-changing GET requests remain unsafe. Evaluate these settings alongside the application’s CSRF defenses.

Anti-CSRF Tokens

Use the framework’s CSRF protection where available. In a synchronizer-token design, generate an unpredictable token bound to the session and validate it on state-changing requests, whether sent in a form field or a header such as X-CSRF-Token. Do not put the token in a URL.

Custom Headers

For a browser API, requiring a custom header such as X-Requested-With can help only if the server rejects requests without it and permits cross-origin requests solely from trusted origins. The header triggers CORS preflight for cross-origin requests; a permissive CORS policy can defeat this design. It does not replace authorization.

How to Add Headers to Your Stack

Vercel (vercel.json)

This example shows Vercel’s header configuration structure. Review it before use: its script policy permits inline scripts and is not a strict CSP. Adapt allowed resources, framing, and browser-feature restrictions, and verify HTTPS on the host and affected subdomains before enabling the HSTS settings.

Next.js (next.config.js)

This CommonJS configuration illustrates Next.js response headers. It does not include a CSP or application-level CSRF protection. Adapt it to the configuration format and hosting path your project uses, then inspect the deployed responses:

Deployment Review Checklist

Use the application security checklist alongside tests of the controls your deployment relies on:

• Inspect headers: Use the Security Headers Checker to see response values, then test browser behavior. A configuration file such as vercel.json or next.config.js does not prove the host applied it.
• Review database access: For Supabase, inspect privileges, RLS policies, and bypass roles. See the RLS guide.
• Check secret exposure: Keep private .env files inaccessible to visitors. The Secret Scanner recognizes supported credential patterns, including OpenAI and Anthropic formats; it does not find every secret.
• Monitor uptime: Use uptime checks for availability. Missing headers do not necessarily cause downtime.
• Review scan coverage: SimplyScan checks eight categories in about 30 seconds, including selected security, speed, and compliance signals. Its URL checks do not test every authentication, XSS, or CSRF path.

Speed, SEO, and AEO

Review AEO signals, performance, and browser security separately. A response-header configuration does not establish how a search or answer engine will rank or cite a page.

Inspect crawler access and available page content when investigating discoverability. Do not infer an answer engine’s decision from a security scan.

The AI visibility guide describes page and crawler signals to review.

SimplyScan's site-health scan helps you balance these needs by grading speed and SEO alongside security.

79% of the 119 live sites SimplyScan has scanned (94 sites) have at least one medium-severity speed issue, such as render-blocking scripts or no route-based code splitting.

Even if you fix security, performance can remain a hurdle.

Deep Dive: The Impact of Missing Headers

If framing is allowed, an attacker may use an overlaid page to trick a user into interacting with your app. Check both X-Frame-Options and applicable CSP framing policy, and test the relevant browser behavior. Header absence alone does not prove that an attack can succeed.

Inspect X-Content-Type-Options together with the served MIME type and upload handling. A .jpg filename does not establish that content is an image, but its presence does not mean the browser will automatically execute embedded JavaScript either. Test how the uploaded resource is served and used.

Test the combined behavior of headers, upload handling, and sensitive actions after deployment changes. Each control addresses a particular boundary.

Security Triage and Compliance

For a security questionnaire, describe the deployed controls and their tests accurately. Header observations may support a relevant review, but they do not establish compliance or replace evidence for the other controls in scope.

Pro Monitoring includes Pro scan credits for full reports. See pricing for the allowance associated with your chosen option.

SimplyScan Pro Monitoring includes scheduled rescans with change alerts and Slack integration. Use the triage workflow to investigate reported changes and rerun relevant tests. These URL observations cover a different scope from GitHub Advanced Security; they do not prove a complete security posture.

Conclusion

CSRF defenses and response headers address different parts of a web application. Configure each for the actual request flows, test the deployment, and revisit the checks when authentication or hosting settings change.

A free SimplyScan URL scan requires no signup and checks selected public secret patterns, headers, and other site-health signals in about 30 seconds. Read the individual findings and coverage limits, then test application-specific risks outside those checks.

Related Guides

• The Ultimate Vibe Coding Security Checklist
• Is Windsurf Safe? A Deep Dive
• Fixing Exposed API Keys in Frontend Code
• Next.js Security Headers Guide

Related Free Tools

• CORS Tester · Inspect selected cross-origin response behavior
• CSP Evaluator · Review supplied policy directives
• SSL Checker · Inspect HSTS and selected TLS observations
• Email Security · Check SPF, common DKIM selectors, and DMARC DNS signals
• Security Headers Checker · View response-header checks and a grade
• Secret Scanner · Check supported inputs for recognized credential patterns

Pro Monitoring costs $24/month.