Secure Basics Before You Share a Link

AI-generated code can be incorrect or insecure. A working demo isn't a security review. Security guides for AI-assisted building all stress the same basics. For the key and access-rule points below, read your build tool's documentation on public and private settings and your database provider's documentation on browser-safe and server-only keys and on access rules. These are the habits from it that matter most when you are the only reviewer.

What to do

• Keep secret credentials on the server or in your host's secret store. Browser code and browser-exposed environment variables are public. Some services provide publishable keys for the browser; use them only with the service's access controls. If a secret was exposed, revoke or rotate it. Moving the value doesn't undo the leak.
• Your build tool marks some settings as public, usually by a name prefix, and bundles them into the browser code. Treat anything with that prefix as public. Your database provider gives you a browser-safe key, which only reaches what your access rules allow, and a server-only key that bypasses those rules and stays on the server. Naming varies by provider, so read their current documentation. Turning on row-level access rules is the first step. You still have to write and test the rules.
• Don't commit .env files to a repository, and turn on automatic dependency alerts from your code host.
• Validate types, lengths and allowed values on the server. Use parameterized database queries. Encode output for where it is shown.
• Define who can read, create, update and delete records, and test those rules as a signed-out visitor, user A, user B and a user from another organization. Use dummy data until access controls are in place. Hiding a button isn't access control.
• Ask the tool to review its own work with specific questions, such as 'check for injection problems' or 'where do secrets appear', then read the answers yourself. A second pass by the tool isn't a sign-off.

A worked example

A builder asks the tool for a feedback form that saves to a database. The first version trusts whatever text arrives. She asks, 'Review this form handler for injection and missing input checks.' The tool finds that a field goes straight into a query and fixes it. The review also flags a database password in the file. She revokes it, creates a new one stored in her host's secret store, and checks the built browser files for any other secrets. Moving the value alone wouldn't undo the leak.

Common mistakes

• Treating a passing demo as proof the app is safe.
• Letting the tool run with admin rights on your database.
• Never asking a person with security experience to look, once, before launch.

Exercise

Run the five checks on your project with dummy data. Put a fake secret (for example DUMMY-SECRET-123) in your code once. Never use a real secret for this test. Build the app, then search the built browser files and network calls for it and remove it. Record each check as pass or fail. Fix what fails, then rerun the checks after the tool's fix. Also decide what user data the app collects and delete what you don't need. If it handles payments, health or children's data, get an experienced human review before you share it.