Yes, with one caveat that decides most of the answer: it depends on who deploys the code. An AI assistant that hands you a folder of files leaves you owning the servers, the secrets and the deploy pipeline. A platform that builds and runs the app on managed infrastructure takes several of those risks off the table before you write anything. This checklist separates the two, so your twenty minutes of review goes on the parts that are genuinely yours.
Does it matter which AI built it?
More than any other factor. GitGuardian's 2026 report found AI-assisted commits leaked secrets at a rate of 3.2 percent against a 1.5 percent baseline across all public GitHub commits, roughly double. Read that number carefully though, because it measures coding assistants: developers generating code into their own repository and deploying it themselves. It is a finding about a workflow, not about AI as such. Change the workflow and the number changes with it, since a platform that never hands you a raw key to misplace removes the opportunity rather than reminding you to be careful.
Is AI-generated code secure by default?
No, and no honest platform will tell you otherwise. AI writes plausible code, not necessarily safe code. It can skip validation, expose data that should be private, hardcode a credential to make a feature work, or import a package that does not exist. Treat the output like a first draft from a fast but unsupervised junior developer: often good, occasionally dangerous, always worth reading.
Why does AI get security wrong so often?
Because security failures are invisible at runtime. A model optimizes for code that works, and "works" means the feature runs when you click it. A missing permission check does not throw an error, it quietly returns the data. A password stored in plain text logs in perfectly. Your app can pass every test you thought to run and still be open, which is why this is a review step rather than a testing step.
Which risks does a managed platform remove?
Build on infrastructure you configure yourself and every risk on this page is yours to handle. Build on a managed platform and several of them stop existing, because there is nowhere left to put the mistake.
- Secret storage. Keys held in an encrypted vault and injected at runtime never sit in your code waiting to be committed. Modulify works this way, and it is the highest-value default of the lot given that leaked secrets are the most common failure by a distance.
- Hosting and HTTPS. No server to harden, no certificate to forget, no half-configured staging box quietly serving real data. Modulify includes hosting, so publishing does not mean configuring infrastructure.
- Database access. A managed database queried through the platform is parameterized by default, which closes SQL injection without you auditing every query.
- The deploy pipeline. Nothing to misconfigure when you press publish instead of wiring up a deployment.
That is not the same as saying your app is secure, and you should distrust anyone who claims it is. It means there are fewer places to go wrong, which makes the places that remain worth real attention.
Which risks are still yours?
These belong to whoever built the app, on any platform, whether a human or an AI wrote the code. This is the list worth twenty minutes.
- Access is checked on the server. Every request returning private data re-checks who is asking. Test it: log in as one user and change the record id in the URL to another user's. If their data loads, you have the most common web app vulnerability there is. Hiding a button is not security.
- Inputs are validated on the server. Client-side validation is a convenience for users, not a defence. Anyone can send a request that skips your form entirely.
- Sessions live in HTTP-only cookies. Not in the browser's local storage, where any script on the page can read them and turn a small scripting bug into a full account takeover.
- Passwords are hashed. If your app stores passwords itself, use bcrypt or argon2 and nothing homemade. If you can read a user's password in your database, so can anyone who gets a copy of it.
- Errors do not leak details. Users see a friendly message. Stack traces, file paths and database errors stay in your logs, because they are a map of your app for anyone probing it.
- Anything already exposed is rotated. A vault protects keys from here on, it cannot recall one you pasted into a chat last month. The same report found over 64 percent of credentials confirmed valid in 2022 were still valid in 2026, so exposure does not expire on its own.
- Custom code and packages are checked. The moment you add your own code or pull in a library, you are back to reviewing it yourself. Confirm every package actually exists and is maintained.
What does the browser actually see?
Everything you send it, which catches people out constantly in web apps because the line between your code and the public is not where it feels like it is. Any key used in client-side JavaScript is visible to anyone who opens developer tools, so a call to a paid API belongs on the server with the key held there. Serve the whole app over HTTPS rather than just the login page. And if you widened cross-origin sharing to make something work while building, tighten it before launch, because on an authenticated endpoint it invites other sites to make requests as your logged-in users.
Which features raise the stakes most?
Three, and each deserves extra attention because each one hands a stranger a lever.
- File uploads. Validate the type and the size, keep files in object storage rather than beside your code, and never trust the filename you were given.
- Payments. Hand card details to a payment provider and let them hold the data. Your app should never see a card number.
- Anything that sends email. Rate limit it, or an open contact form becomes a spam relay with your domain's reputation attached.
What is slopsquatting and should I worry?
Slopsquatting is when attackers publish malicious packages under names that AI models tend to hallucinate, waiting for someone to install one on an assistant's recommendation. If your app pulls in a package the AI suggested, confirm it is real, widely used and maintained before trusting it. Thirty seconds of checking prevents a supply-chain compromise that is very hard to unpick later.
Do I need a security review for a simple site?
A marketing site with no accounts and no data is low risk. Build away. The moment you add logins, payments, file uploads or personal data, run the list. Risk scales with what the app can reach, not with how it was built. A hand-written app with a missing permission check is exactly as exposed as an AI-written one.
How often should I run through this?
Every time you add something that touches data, not once before launch. Building this way makes changes cheap, which means the shape of your app moves faster than your mental model of it. The list is short on purpose so that re-running it stays realistic.
The Modulify take
The useful question was never whether AI can be trusted to write code. It is which risks your setup removes and which it leaves with you. Managed secrets, hosting and databases delete a whole category of mistake before you start, and Modulify is built that way deliberately. What no platform can do is decide who should be allowed to see a given record, so that part stays a short review you run yourself. For the wider context, start with what vibe coding actually is, then pair this with From Prototype to Production. Build on a platform with secure defaults.
