How to secure a Windsurf app: a pre-launch security checklist (Windsurf is now Devin Desktop)

Last updated October 28, 2026 · By Ember, SniffPup

Short answer: not automatically. Windsurf is a code editor with an AI agent, so your app is exactly as secure as the code, keys and database settings it ends up with. The agent wrote your app in an afternoon; a stranger can read everything your site sends to the browser in seconds. This checklist covers both.

Quick name check: Cognition renamed Windsurf to Devin Desktop on June 2, 2026, and in September 2026 the Cascade agent was removed in favor of Devin Local. Same editor, new collar. If your project started in Windsurf, everything below still applies.

Ember, our black Pomeranian detective, sniffs your published site the way a stranger would, minus the bad intentions: secret keys in your HTML and JavaScript (masked in the report), public /.env and /.git files, a downloadable source map, missing security headers, cookie flags, HTTPS, CORS and Supabase or Firebase read access using only the public config your site already ships. It's passive: no logins, no attack traffic, and she never uses a secret key she finds. She can't see your source code, your editor settings or anything behind a login.

1. Keep .env out of git (and know what the agent can see)

Per the Devin Desktop ignore-file docs, indexing skips paths in your .gitignore, node_modules and hidden paths (names starting with a dot), and files matched by .gitignore can't be edited by the agent. A .devinignore file keeps extra paths out of indexing and agent access; the older .windsurfignore and .codeiumignore files still work. With the Devin Local agent, access to gitignored files is off by default, and you can add deny rules such as Read(**/*.pem) for files it should never open.

That's about the agent, though. None of it stops a .env from being committed or uploaded with your site.

How to check: make sure .env and .env.* are in .gitignore, then run git log --all -- .env to see whether one was ever committed. If a real key was committed or pasted into a chat, revoke it at the provider and make a new one. Deleting it from the code is like hiding the treat after the dog has seen it: too late. Our leaked API key guide has the rotation steps.

2. Keep secret keys out of NEXT_PUBLIC_ and VITE_ variables

Windsurf projects are often Next.js or Vite apps. Next.js puts every variable that starts with NEXT_PUBLIC_ into the browser bundle, and Vite does the same with VITE_. That's fine for public values like a Supabase project URL, a Supabase anon or sb_publishable_ key, or a Stripe pk_live_ key. It is never fine for a Supabase service_role or sb_secret_ key, a Stripe sk_live_ key or an OpenAI sk- key. Calls that need a secret belong in server code: an API route, a server action, a Netlify or Vercel function, or a Supabase Edge Function.

How to check: open your deployed site, open DevTools → Sources and press Ctrl+Shift+F (Cmd+Option+F on Mac). Search for service_role, sb_secret_, sk_live_, sk- and PRIVATE KEY. Our guide to finding exposed API keys on your website has the full list of patterns, and the frontend env leak checker does a quick pass for you.

Paste this into your agent: "Find every API key or secret used in client-side code or in NEXT_PUBLIC_ or VITE_ variables. Move each secret to a server-side route or function, read it from a server-only environment variable, and list which keys I need to rotate."

3. Turn on Row Level Security if you use Supabase

If your frontend talks to Supabase with the public anon key, Row Level Security is the only thing standing between strangers and your rows. The anon key is meant to be public; it's only as safe as your policies. Every table in an exposed schema needs RLS on, and each policy should be tied to the user (for example auth.uid() = user_id) unless the data really is public. A policy that says using (true) is a doggy door for everyone.

How to check: run Supabase's Security Advisor, then test with two accounts: user A should never see or change user B's rows. Our Supabase RLS checker guide has the SQL and a signed-out test, and RLS policy examples has copy-paste policies.

4. Make sure /.env and /.git aren't public

Static sites and simple deploys sometimes upload the whole project folder, dotfiles included. Then yoursite.com/.env hands out your keys and yoursite.com/.git/config hints that your whole history is downloadable. Build tools like Next.js and Vite normally publish only their output folder, but it's worth ten seconds to check.

How to check: open /.env, /.env.local and /.git/config on your live site. You should get a 404 or your normal page, never file contents. The free .env file exposure checker tries the common paths for you and shows variable names only, never values.

5. Add security headers

Headers are cheap armor: they tell browsers to stick to HTTPS, stop other sites from framing yours and stop guessing file types. Agents rarely add them unless asked. On Netlify (where App Deploys and many Windsurf sites live) add a _headers file to your publish folder or a [[headers]] block in netlify.toml; on Vercel use headers in vercel.json or next.config. Start with Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy and X-Frame-Options (or frame-ancestors in a Content-Security-Policy).

How to check: the free security headers checker shows what's missing in a few seconds.

6. Know where your app is actually deployed

Windsurf's App Deploys put sites on a public windsurf.build address hosted on Netlify. The App Deploys docs say they're intended primarily for preview purposes, that your code is uploaded to their servers, and that production apps with sensitive data should be claimed and follow security best practices. The Devin Local agent doesn't support App Deploys, so newer projects usually live on a host you chose. Wherever it lives, if a stranger can open the URL, so can Ember.

7. Keep the agent on a short leash

This one protects your laptop more than your users, but it's worth a minute. Cascade had auto-execution levels up to Turbo, which runs every terminal command except those on your deny list (terminal docs). Devin Local swaps that for allow, ask and deny rules on file reads, writes, commands, web fetches and MCP tools, and asks before calling any MCP tool by default. Put destructive commands like rm and anything that deploys or touches production on deny or ask, and only add MCP servers you trust.

8. Protect pages on the server, not just in the browser

Hiding a button or redirecting in the browser doesn't protect anything; it's a "please don't" sign, not a fence. Admin-only data and actions need a server-side check or a database policy. Open your app signed out in a private window and try links that should need a login, then sign in as a normal user and change an ID in a URL to someone else's record. You should be refused both times.

Using other builders too? See Is my Cursor app secure?, Is my Lovable app secure? and the full vibe-coded app security checklist.

FAQ

Facts about Windsurf and Devin Desktop checked Oct 28, 2026 on Cognition's own docs and blog. A clean report is not a guarantee of security. Only scan sites you own.

Run a free scan →