I built a desktop assistant that reads my Gmail, my calendar and my Notion. It pulls trending social media topics into a Notion board every morning and drafts replies to emails I have not answered. It needed API keys for all three services, and the AI parts cost me money every time it ran.
Before I pushed it to GitHub and made the repository public, I ran a security check. I asked the AI that helped me build it to go through the whole project and find anything sensitive, then I checked the flagged files myself.
That habit came from paying attention rather than from any training. I am a digital marketer, not a security engineer. But a lot of us are building things now that we would not have attempted two years ago, and most of the security advice out there is written for engineering teams shipping commercial products. This post is the version I wanted when I started.
Everything below comes from OWASP, a nonprofit that maintains the security risk lists the software industry actually uses, and from published academic research. Every claim links to its source so you can check it yourself.
What the research says about AI-written code
The most useful study here is a large user experiment from Stanford, published at the ACM Conference on Computer and Communications Security. Perry, Srivastava, Kumar and Boneh gave participants a set of security-related programming tasks. Some had an AI coding assistant, some did not.
Two findings matter. Participants with the AI assistant wrote significantly less secure code than those without one. And they were more likely to believe their code was secure (Perry et al., 2023).
Read those together. The tool raised confidence and lowered accuracy at the same time. That combination is what makes this worth writing about, because you cannot feel the problem happening.
One caveat worth stating. The study used an OpenAI model from 2022, and models have improved since. What has not obviously changed is the human half of the finding, which is that people who feel confident stop checking.
You will also see a lot of statistics quoted on this topic, including figures from Veracode, Carnegie Mellon and CodeRabbit about how often AI-generated code fails security testing. Those numbers are widely repeated, but the ones I traced came through secondary coverage rather than the primary reports, and several come from companies that sell security products, which does not make them wrong but does mean they deserve a second look. I have left them out of my argument rather than pass along figures I could not verify at source. The OWASP guidance and the Stanford study below are enough on their own.
Six things worth checking
Out of a long list of risks, these six are the ones that apply to a marketer who built a landing page, a waitlist or a small tool.
1. Your API keys end up in a public repository
What you built. Anything that connects to another service. An email tool, a form that writes to a database, a feature that calls an AI model.
What goes wrong. Those keys have to live somewhere in your project. AI tools will write them directly into a file, because that is the fastest way to make the thing work. When you push the project to GitHub and make it public, that file goes up with everything else. Automated scanners crawl public repositories looking for exactly this, and a leaked key can be used to run up charges on your account or to reach the data behind it. GitHub runs its own secret scanning across public repositories for the same reason.
What to do. Before you make anything public, ask the AI to search the whole project for API keys, passwords and tokens, then open the files it flags and check them yourself. Keys belong in a separate environment file that is excluded from uploads. If a key has already gone public, replace it with a new one rather than deleting it from the file, because the version history keeps a copy of everything you ever committed.
2. Anyone can read your database
What you built. A waitlist or contact form. Submissions come in and land in Supabase or Firebase. It works.
What goes wrong. Your page talks to that database using a key that sits in your page's code, where any visitor can find it by viewing the source. The thing standing between strangers and your table is a setting called Row Level Security, which decides who is allowed to read what. AI tools often leave it switched off, or write a policy that permits everyone, because a permissive policy is the one that definitely works during testing.
This falls under Security Misconfiguration, which is eighth on the OWASP API Security Top 10.
What to do. In Supabase, open your dashboard, then Authentication, then Policies. Turn Row Level Security on for every table holding real data. Then ask your AI to write a policy that checks which user is logged in, rather than one that returns true for everyone.
3. Anyone can download every file people upload
What you built. A page where visitors upload something. A photo, a CV, a receipt, an ID.
What goes wrong. Those files sit in a storage folder online. Each individual link works correctly, so nothing looks broken from your side. But the folder itself is often configured so that anyone can request a list of everything inside it, and then open all of it. A file being hard to guess is not the same as a file being private.
This is Security Misconfiguration again.
What to do. Open your storage settings and check two things: whether the bucket is public, and whether listing its contents is allowed. Turn listing off. For anything genuinely private, serve files through links that expire after a short time rather than permanent public URLs.
4. One person can run up your entire AI bill
What you built. A caption generator, an image tool, anything that calls a paid API. Every click costs you money.
What goes wrong. Nothing stops one person clicking it fifty thousand times, and a simple script can do that in an hour. OWASP calls this Unrestricted Resource Consumption, fourth on their API list, and their guidance is explicit that rate limiting and hard usage caps are the defence.
There is a trap inside this one. Limiting usage per user does nothing if the tool works without an account, or if creating a new account is free and takes ten seconds. The question is not how much one user can consume. It is how much one stranger can consume.
What to do. Ask your AI to add a limit per user and per IP address. Then go into your API provider's billing settings and set a hard daily spending cap, so your worst case is a number you chose rather than an open tab.
5. People can talk your chatbot out of its instructions
What you built. A chat assistant on your site. You gave it a prompt telling it to be helpful and never to discuss pricing.
What goes wrong. Someone types a message telling it to ignore those instructions, and often it does. This is called prompt injection, and OWASP ranks it as the number one risk for AI applications.
It gets more serious if your assistant can take actions rather than just talk. If it can look up customer records, send emails or write to a database, a well-worded message can get it doing those things on a stranger's behalf. OWASP's own guidance notes that there is no fully reliable prevention for this, and recommends layered defences including least-privilege access and human approval for high-risk actions (OWASP, 2025).
What to do. Try to break your own bot before someone else does. Tell it to ignore its rules. Ask it to show you its instructions. Then make sure anything sensitive sits behind a real permission check on your server, not behind a sentence in the prompt. A line of instruction is a request. A server-side check is a rule.
6. Your users can read each other's data
What you built. A tool with logins. Each person has a page with a number in the address bar, something like /report/1045.
What goes wrong. Change 1045 to 1047. If someone else's report opens, every user can read every other user's data.
This is the one OWASP ranks first, as Broken Object Level Authorization. You may also see it called IDOR, which stands for Insecure Direct Object Reference and is the older name for the same problem. OWASP calls it extremely common in API-based applications and rates it widespread, easy to exploit and easy to detect, and notes that it happens because the server trusts the ID sent by the browser instead of checking who is asking. That detectability rating is the useful part: this is not a subtle flaw, it is one nobody checks for.
It is close to invisible from the inside, because everything works perfectly when you are logged in as yourself.
What to do. Your server has to confirm that the logged-in user owns that record, on every request. OWASP also recommends using random, unpredictable IDs rather than sequential numbers, so records cannot be walked through one by one. Hiding the link in your interface does not count, because the address bar is not something you control.
The audit prompt
You do not need to learn to code to run this. You need to ask a better question. Paste this into whatever tool you built the project with:
Check whether any API keys, passwords or tokens are written into files
that would go public if I pushed this repository.
Then check this project against the OWASP API Security Top 10 (2023) and
the OWASP Top 10 for LLM Applications (2025). For anything you find, tell
me the risk in plain language, which file it is in, and what to change.
Specifically check:
- Row level security on every database table holding real data
- Whether my storage buckets are public or allow listing
- Rate limits and spending caps on anything that costs money per call
- Whether any record can be opened by changing a number in the URL
- Whether any AI feature can take actions without a server-side
permission checkRead what comes back rather than accepting it. The point of the prompt is to give you a list you can work through, not a verdict you can trust unread.
The part worth remembering
All six of these pass a normal test. That is not a coincidence. You test as the person who is allowed in, using the account that is supposed to have access, clicking the links your own interface gives you. Every one of these problems only appears when someone does something your interface did not offer.
Your project working is not the same as your project being safe. Run the check before anything holding real people's details goes live.
A note on sourcing
I checked every OWASP page linked above directly, and the Stanford paper is available in full at the links given. I deliberately left out several widely quoted statistics about AI code vulnerability rates, because I could only find them repeated in secondary coverage and could not confirm the figures against the original reports. If you have seen a number in this space quoted without a link, that is usually why.