Is the app Windsurf built secure?

Windsurf is an AI code editor. Its agent, Cascade, edits files across your project and can run terminal commands. You choose how much Cascade runs without asking, and you can give it rules that it follows in every session.

The editor's safety comes down to those settings. Keep command execution on approval for anything that changes files outside the project, installs packages or touches credentials, and read commands before you accept them.

Your app's safety is about the code Cascade wrote and where you deployed it. Windsurf does not review that for you by default, and whatever host you use serves exactly what you give it.

• Keys pasted into source while getting a feature working, such as an OpenAI key in a React hook.
• Secrets exposed through a public env prefix (VITE_, NEXT_PUBLIC_, EXPO_PUBLIC_) because client code could not read them otherwise.
• A .env file missing from .gitignore, or saved inside a static folder that gets deployed as is.
• Session cookies created without Secure or HttpOnly in custom login code.
• An Express or Flask server with no security headers.
• CORS set to allow any origin with credentials after a development error.

These happen because the agent optimises for the task in front of it. A rule file that states your security requirements changes what it reaches for.

Windsurf supports workspace rules that Cascade reads. Add a short set that covers the mistakes above:

Security rules:
- Read secret keys only on the server from environment variables.
- Never use a public prefix (VITE_, NEXT_PUBLIC_) for a secret.
- Never hardcode keys. Never write .env into public/, static/ or the build output.
- Session cookies are Secure, HttpOnly and SameSite=Lax.
- CORS allows only our production origin.

Audit this project for security before deploy. Find hardcoded keys and secrets in public env variables, and move those calls to the server. Make sure .env is in .gitignore and never copied into the build output. Add security headers for our host and make session cookies Secure and HttpOnly. Restrict CORS to our own origin. Show me each change first.

• Netlify: a _headers file in the publish folder, secrets in site environment variables used by functions.
• Vercel or Next.js: headers in next.config.ts or vercel.json, secrets without the NEXT_PUBLIC_ prefix.
• A Node server: helmet or res.setHeader, secrets in the server's environment.
• nginx: add_header lines and a location block that denies dotfiles such as .env and .git.

If you used a one-click deploy from inside the editor, check which host received the site and open its dashboard, since that is where headers and environment variables live.

1. Add workspace rules before Cascade writes much code.
2. Search the source and build output for sk_live_, sk-, sk-ant-, AKIA, ghp_ and BEGIN PRIVATE KEY.
3. Run git log --all -- .env to confirm no env file was ever committed. Rotate anything that was.
4. Check every public-prefixed env variable.
5. Set headers and cookie flags for your host, then deploy.
6. Scan the live URL and fix what it reports.

An outside scan checks what your deployed site exposes to any visitor: secret keys in the HTML and your own JavaScript bundles, public .env and .git files, security headers and CSP strength, the https redirect, cookie flags and CORS. It does not read your repository, log in, or test for injection bugs, so pair it with a code review of your API routes.