Is Claude Code safe? A security guide for Claude Code projects

Claude Code runs in your terminal or IDE with access to your files and shell. By default it asks before it edits files or runs most commands, and you decide how much to loosen or tighten that. This guide covers both sides: locking down the agent, and checking the app it builds.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

Common security risks in Claude Code apps

1. 1. Secrets committed during quick fixes

   A key pasted into code or a prompt to get something working tends to stay in the file, in Git history and sometimes in the front-end bundle. Move it to an environment variable that only server code reads, and rotate it.

2. 2. Checks on the page but not the endpoint

   Generated auth often hides a button without protecting the route behind it. Every API route and server action has to verify the session and the user's permission itself.

3. 3. Packages added without a second look

   Coding agents sometimes suggest packages that do not exist or whose names resemble popular ones. Check the name, publisher and history before you install, and commit the lockfile.

4. 4. Missing or permissive security headers

   No Content-Security-Policy, HSTS or clickjacking protection, or a CSP with unsafe-inline and unsafe-eval, leaves an injected script much easier to run.

5. 5. Debug output and exposed files in production

   Stack traces, verbose errors, public source maps and deployed .env or .git paths reveal your stack and sometimes your keys.

What a FixPrompt scan checks

Passive checks on your public site, the same way a visitor's browser loads it. No attacks, no logins, no data queried.

• Secret key patterns for 30+ providers in JavaScript bundles and HTML
• Content-Security-Policy strength, HSTS, clickjacking and Permissions-Policy
• Session cookie flags and lifetime
• Common API paths that answer anonymous requests, plus rate-limit headers
• Debug headers, server banners, error pages, internal hostnames and HTML comments
• Public .git, .env, source maps and backup files

Copy-paste fix prompt

Paste this into Claude Code, Cursor, Codex or any coding agent with access to your repository. A scan gives you a prompt tailored to the issues found on your live site.

Review this project like a security engineer and fix issues in priority order. You can start with /security-review on the current branch, then go further:

1. Search the code and git history for hard-coded secrets. Move them to environment variables that only server code reads, and list the keys I must rotate.
2. Check every API route and server action: it must verify the session and the user's permission before reading or changing data.
3. Add a strict Content-Security-Policy (no unsafe-inline or unsafe-eval for scripts), plus HSTS, frame-ancestors, X-Content-Type-Options and Referrer-Policy.
4. Set session cookies with Secure, HttpOnly and SameSite=Lax, and add rate limiting to routes that call paid APIs.
5. Remove debug output and source maps from production, and list any dependency you added that I should double-check.

Make small, reviewable commits and tell me how to verify each fix.

Want rules your agent follows on every task? Get security rules for Cursor, CLAUDE.md and AGENTS.md.

FAQ

Does Claude Code have a built-in security review?

Yes. The `/security-review` command runs a security pass over the changes on your current branch. It reviews code, so it complements a scan of the deployed site rather than replacing it.

How do I stop Claude Code from reading my .env file?

Add deny rules such as `Read(./.env)` under `permissions.deny` in `.claude/settings.json`. Keep real secrets out of the repository as well, and rotate any key the agent has already seen.

Does this work with Cursor, Codex or Copilot too?

Yes. The fix prompt is plain text for any coding agent with access to your repository, and the scan only looks at the public, deployed site.