Your database key is written on the page

There is a fast way to see what your site says about itself. Open it in a tab, right click anywhere, pick "view page source". What shows up is not a backstage area you broke into. It is exactly what every visitor receives, because that is what their browser needs in order to draw the page.

Now search that text for words like key, token, secret or apikey. If one of them is followed by a long run of letters and numbers, you just found the single most common finding in apps built with AI.

How it got there

You asked for something reasonable. Save this to the database. Send an email when someone signs up. Charge the card. The assistant wrote code that does it, and the fastest way to make that code work is to have the page talk to the service directly. For the page to talk to the service, the credential has to travel with the page.

Nobody was careless. The app worked, the demo went well, and the part that would have moved the credential to a server nobody can read was extra work that never got asked for. This is why it is so common: the shortcut and the working app are the same thing.

What someone can do with it

• Read your whole customer table: emails, phone numbers, addresses, whatever else is in there.
• Write to it: create records, change a price, delete a row.
• Send email as you, when the key belongs to a sending service.
• Spend your money, when the key belongs to something you pay for per use.

None of that looks like a break-in from the inside. There is no alarm, no strange login, nothing in the logs that stands out. As far as the service is concerned, whoever asked had the key, so whoever asked was you.

The key says who is speaking. The rule says what that person is allowed to see.

The rule nobody turned on

In the databases most used by people building with AI, permission is a separate layer from the key, and it has to be written table by table. A table with no rule behaves the way it was set up to behave on day one, which is usually the most permissive thing that lets your app work.

That is the part worth sitting with. The default is not malicious and it is not a bug. It is a starting point that assumes you will come back and narrow it down. Most apps never come back, because nothing visible changes when you do not. The failure has a name and a place on the industry list, under configuration: OWASP Top 10 in plain English runs through all ten of them.

What to do today

• View the source of your live page and search for key, token, secret and apikey. Also check the network tab: keys often travel in requests instead of the HTML.
• If you find one with service, secret or admin in the name, rotate it now. A rotated key makes the copy someone may already have useless.
• Turn on the permission rule for every table that holds anything about a person, and check it by opening the app while signed out.
• Ask the tool you built in to move that call to the server side, and tell it plainly: the key must not reach the browser.

None of this requires you to become a security person. It requires knowing that the page is public, that the key is part of the page, and that the rule is a separate thing you have to switch on. And if someone already handed you a list of findings and nothing came of it, a report with 147 findings fixes nothing.