Deploys and hosting
These guides are about the running site, not the editor. Secrets belong in the host's server environment, preview deploys should not hold production credentials, and the response should tell the browser how it may be framed and which origins may call it. The host you pick changes where you type the variable. It does not change the checks.
Guides
How to deploy your vibe-coded app securely
Put server secrets in the host's environment, keep them out of the browser bundle, and do not give a preview deploy the production database or a public URL it does not need.
Missing security headers
Headers tell the browser not to sniff content, not to load you in a frame, and which scripts are allowed. They limit damage, and they do not replace auth.
CORS wide open
Reflecting any website's Origin and allowing credentials means that website can call your API as the logged-in user.
Questions
Can a preview deploy use the production database?
No. A preview URL exists so a change can be clicked before it merges. Point it at a preview database and preview API keys. Railway does not copy sealed variables into pull-request environments. Render can set a separate preview value. Vercel can scope a variable to Preview instead of Production.
Do security headers replace auth?
No. Nosniff, a frame policy, a referrer policy, and a content security policy limit damage in the browser. They do not decide who can read a row. Set them, and still check the server.
When is a wide-open CORS header a real bug?
When the API uses cookies and reflects whatever Origin the browser sent. That other site can then call your API as the logged-in user. An allowlist, or no CORS middleware, is the fix. A public API that does not use cookies is a different case.