Is Claude Code Safe? Security Risks and the Checklist Before You Ship

You're using Claude Code to build something real, and a thought stops you before launch: is Claude Code safe to ship from? Maybe you saw a study about AI-written code having security holes. Maybe a teammate raised an eyebrow. You're not a security engineer — you just want to know whether the app you're about to put in front of users is going to leak data or get broken into.

Here's the calm version of the answer. Claude Code is a developer tool, and the tool itself is not the issue. The thing to watch is a property of AI code generation in general: AI assistants are very good at producing software that works, and noticeably worse at producing software that's secure by default. That's true across the field, not specific to one assistant.

This post explains what the research actually found, the real risks to check in a Claude Code app, and a concrete checklist to run before you ship.

⚡ TL;DR

• Claude Code is safe to use — it's a developer tool, and the concern isn't the tool but the well-documented tendency of AI codegen, broadly, to ship working code with security gaps.
• In independent testing, even the strongest AI agent combinations still produced insecure code at high rates. This is a property of AI codegen, not a knock on any single tool.
• The risks to check are the usual ones: missing data access rules (RLS), secret keys in the frontend, missing security headers, and server-side request flaws — all findable before you launch.

Is Claude Code safe? The short answer

Claude Code is a coding assistant. Using it does not make your app insecure, and it's a powerful tool in capable hands. The honest framing is this: the risk lives in the code that gets generated, not in the act of generating it.

Why? Because AI assistants optimize for the goal you give them, and the goal you give them is almost always "make this work." A feature where every user can read every record works in a demo. A page that calls an external URL with no guardrails works in a demo. The security hole doesn't show up in the preview — it shows up when an attacker tests the parts of your app you never clicked.

So when people ask "is Claude Code safe," the useful answer is: the tool is fine; the discipline you have to bring is reviewing what it ships. The rest of this post is about doing exactly that, with the research to back up why it matters.

What the research actually found

Two independent results frame this well, and both point at AI codegen as a category rather than at any one product.

Even the strongest tested agent still shipped insecure code. Carnegie Mellon's SusVibes benchmark evaluated AI coding agents on both functional correctness (does the code work) and security (is it safe). The best combination tested — the SWE-Agent framework paired with Claude Sonnet 4 — reached 61% functional pass but only 10.5% security pass. Read that again: over 80% of the solutions that worked correctly still contained a vulnerability. The takeaway isn't "this model is bad." It's the opposite — this was the strongest combination tested, and it still shipped insecure code most of the time. Functional and secure are two different bars, and AI clears the first far more reliably than the second.

The gaps cluster in predictable places. A December 2025 study by Tenzai built 15 apps across a range of AI coding tools — Cursor, Claude Code, Replit, Devin, and OpenAI Codex. The findings were strikingly uniform: every tool introduced server-side request forgery (SSRF), zero implemented CSRF protection, and zero set security headers. When the same gaps appear across every tool tested, that's not a tool problem — it's an AI-codegen problem. The defaults nobody asked for (a header that says "don't let other sites embed me," a check that an outbound request isn't being abused) don't get added unless a human asks.

And the broader picture matches. Veracode's 2025 analysis of over 100 models across 80 tasks found 45% of generated code samples failed security tests or introduced an OWASP Top 10 vulnerability — a figure that, in Veracode's words, "make[s] the wrong choices nearly half the time, and it's not improving." None of this is a reason to stop using AI to build. It's a reason to check the output before you ship it.

The real risks when you build with Claude Code

Here are the specific gaps to look for in an app built with Claude Code. These map directly to the research above.

Missing data access rules (RLS). If your app has a database — and most do — the most important control is whether each user can only see their own rows. The technical name is RLS (Row Level Security): a rule the database applies to every query so it returns only the rows a given user is allowed to see. AI tends to wire up the database so the feature works, and skip the policies that restrict access. A table with RLS off, or a policy set to "allow everyone," returns every record to anyone. This is the most common way AI-built apps leak. (Full walkthrough: Supabase security for AI-built apps.)

Secret keys in the frontend. Your app likely calls paid services — an AI model, an email provider, a payments backend — and those calls use keys. Some keys are public by design and meant to ship in the browser. Others are secret and must stay on the server. AI sometimes drops a secret key straight into frontend code to make a call succeed. If a secret key is in your shipped JavaScript, anyone can pull it out and spend on your account. Know which is which: exposed secrets and API keys in frontend code.

Missing security headers and CSRF protection. These were the universal gaps in the Tenzai study. Security headers are short instructions your server sends that harden the browser against common attacks. CSRF (Cross-Site Request Forgery) protection stops a malicious site from tricking a logged-in user's browser into performing actions they didn't intend. Neither is added by default by AI codegen. Both are quiet risks — invisible until exploited — and both are addable.

Server-side request forgery (SSRF). Every tool in the Tenzai test introduced this. SSRF happens when your app can be tricked into making a network request on the attacker's behalf — for example, fetching a URL the user supplies without checking where it points, letting an attacker reach internal systems. If your app fetches URLs, processes uploads from links, or calls webhooks, this is worth a hard look.

How to check your Claude Code app

You can catch most of these yourself before launch. Set aside an afternoon.

1. Test as a second user. Create two accounts. As user A, note a record's ID. As user B, try to open it directly. If it loads, your access rules aren't restricting rows.
2. Search your shipped code for secret keys. Open your live app, open browser developer tools, and look through the Sources and Network tabs. Search for prefixes like sk_ or the word secret near a service name. A secret key in the frontend is an emergency.
3. Check for security headers. Use any free "security headers" checker, or your browser's Network tab, against your live URL. Missing headers like a content-security-policy or X-Frame-Options confirm the Tenzai pattern and are worth fixing.
4. Look for unguarded outbound requests. If any feature takes a URL or link from the user and fetches it, that's your SSRF candidate. Confirm the app restricts where it's allowed to connect.

The pre-ship checklist for Claude Code

Run this before real users touch your app.

• RLS is on and restrictive. Every table of user data enforces "users see only their own rows," not "allow everyone."
• No secret keys in the frontend. Shipped JavaScript contains no sk_-style or otherwise secret keys. Publishable keys are fine.
• Second-user test passes. A second logged-in account cannot read or change the first user's data by altering an ID.
• Security headers are present. A headers check on your live URL returns the standard protective headers.
• CSRF protection exists on any state-changing action (anything that writes, deletes, or pays).
• Outbound requests are guarded. Any feature that fetches a user-supplied URL restricts where it can connect (no SSRF).
• Re-checked after every change. Each new feature gets the second-user test again, because new code can open new holes.

FAQ

Is Claude Code safe to build production apps with?

Yes — Claude Code is a developer tool, and using it is not the risk. The risk is that AI-generated code, across every tool studied, tends to ship working software with security gaps the AI wasn't asked to close. Build with it, then review the output against the checklist above before you launch.

Does Claude Code write insecure code on purpose?

No. Like all AI coding assistants, it optimizes for the goal it's given — usually "make this work" — and security defaults that nobody explicitly requested often don't get added. Independent research found this across the field: even the strongest agent combination tested passed only about 10.5% of security checks while passing 61% functionally. It's a category property, not intent.

What's the single most important thing to check in a Claude Code app?

Data access. If your app has a database, confirm that one user cannot read another user's records — by testing as a second account and trying to open the first user's data directly. Missing access rules are the most common and most damaging gap in AI-built apps.

The bottom line

Claude Code is safe to use; the work is reviewing what it produces. The research is consistent — even the best AI agent combinations ship working code with security holes most of the time, and the gaps cluster in predictable places: missing access rules, secret keys in the frontend, missing headers, and server-side request flaws. An attacker can find those in minutes by testing the parts of your app you never clicked. Find them first, and keep checking, because your AI ships new code (and new holes) on every deploy.