Authorisation on the server
Every privileged action re-checked in the backend, because a hidden button is not a permission.
Security hardening
Close the holes AI builders leave wide open
An API key in the browser bundle. Authorisation checked only in the UI. It's the same short list nearly every time, and every item on it is exploitable in an afternoon.
In short
Security hardening for an AI-generated app means moving trust to the server: authorisation re-checked in the backend rather than enforced by hiding buttons, secrets held in a managed vault instead of the client bundle, every input validated server-side, and rate limits on anything that costs money or sends mail. Gen2Prod reviews the codebase against the OWASP Top 10, fixes what is actually exploitable, and hands you a report with every finding rated and reproduced.
- Typical timeline
- About 1 week
- Reviewed against
- The OWASP Top 10
- Covers
- Auth, secrets, validation, rate limiting, headers, dependencies
- You get
- A written report with every finding rated and reproduced
You probably need this if…
- An API key is in the frontend code because that's where it worked.
- The admin page is protected by hiding the link to it.
- Validation lives in the form, and only in the form.
- Anyone can call the endpoint that sends email or spends AI credits.
- No dependency has been updated since the app was generated.
What security hardening covers
Secrets out of the bundle
Keys moved into a managed vault or server-side environment, rotated, and the exposed ones revoked.
Server-side validation
One schema validating input at the boundary, shared with the form so the error messages still match.
Rate limiting & abuse controls
Caps on signup, password reset, uploads, and every endpoint that calls a paid API on your behalf.
Session & auth hardening
Correct cookie flags, sensible token lifetimes, and a password-reset flow that can't be used to enumerate your users.
Dependencies & headers
Known-vulnerable packages upgraded, CSP and security headers set, and both wired into CI so they stay that way.
How we run it
- 1
Review the real thing
We read the code against the OWASP Top 10 and try the obvious attacks on a copy of the app, rather than working an abstract checklist.
- 2
Rank by exploitability
Findings sorted by what an attacker could actually do and what it would cost you. Critical items are fixed the same week.
- 3
Verify and keep it closed
Each fix is re-tested against the exploit that proved the bug, and the check moves into CI where it can't quietly regress.
What you get back
- A written security report, every finding rated and reproduced
- Fixes shipped for everything rated critical or high
- Secrets moved, rotated, and the exposed ones revoked
- Dependency and header checks running in CI
- A note on what we'd do next, and the point at which it starts to matter
Tools we reach for
- OWASP Top 10
- Supabase Auth, Clerk & Auth.js
- Zod
- Content Security Policy
- Managed secret vaults
- Dependabot & npm audit
- Edge rate limiting
Security hardening — questions we get asked
Is this a penetration test?
No. A pentest attacks a running system from the outside; we review the source, fix what's wrong, and re-test the fixes. At this stage that's usually more useful — most AI-built apps have findings you can read straight out of the code. We'll say so plainly if a formal pentest is the right next step.
My API key is already in the frontend. How bad is that?
Assume it is public, because anyone can read a browser bundle. Treat it as leaked: rotate the key, move the call server-side, and check the provider's usage log for what it was used for. That's the first thing we do.
Will you sign an NDA?
Yes, on request, before you send us anything. We work from read-only copies and your code stays yours.
Can you do this without slowing our releases down?
The fixes ship as small pull requests alongside your normal work, and the CI checks exist so the next release doesn't reopen what we closed.
Often paired with
All servicesDeploy & CI/CD
Deploys should be boring: push, watch it go green, roll back in one click if it isn't. We set that up once and you stop thinking about it.
Learn moreMonitoring & alerts
The worst way to learn about an outage is a support email. Monitoring is a couple of days of work and it changes how the whole thing feels to run.
Learn moreAI feature build-out
The demo worked. Then it needed streaming, retries, cost caps, and an answer for what happens when the model is wrong. That's the part we build.
Learn more