Security & Data Hardening
Hardening means moving every rule that protects user data out of the browser, where it can be bypassed, and into the database and server, where it cannot.
AI coding tools are good at producing an interface that behaves correctly when you use it as intended. They are much less reliable at the part nobody sees: what happens when someone changes the user ID in a request, calls an endpoint directly, or reads the JavaScript your site sends them.
This is a measured pattern, not a rumor. Research published by Veracode found that while AI-generated code became dramatically better at being syntactically correct between 2023 and 2025, the share passing security tests stayed flat at roughly 45–55%. The models got better at writing code, not at writing safe code.
This sounds like you if…
- “I read that my Supabase key is exposed and now I'm panicking.”
- “Users can see the admin page if they type the URL directly.”
- “My API keys were in the repository and I don't know for how long.”
- “Payments sometimes get credited when they shouldn't.”
- “I don't know whether one customer can read another customer's data.”
What this covers
- Enable and correctly write row-level security on every table, then test the policies with real queries rather than assuming they work.
- Find and rotate exposed credentials, and move secrets into environment variables and server-side code where they belong.
- Move authorization checks to the server. A hidden button is not a permission.
- Verify webhook signatures on payment and third-party integrations, so a forged request cannot mark an order as paid.
- Add rate limiting to endpoints that cost money when called repeatedly, particularly anything that calls a paid AI API.
- Separate development, staging, and production environments and their databases, so a mistake in one cannot destroy another.
- Set up error monitoring, so you find out about failures from a dashboard rather than from a customer.
What this is not
Stated up front so nobody buys the wrong thing.
- We do not perform penetration testing or red-team exercises.
- We cannot certify compliance with HIPAA, SOC 2, PCI-DSS, or similar frameworks. If you need that, you need an assessor, and we will tell you so.
- No engineering work can guarantee an application is free of vulnerabilities.
Worth knowing
Security & Data Hardening — questions
How do I know if my database is actually exposed?
The fastest check: open your app in a private browser window, sign out, and try to fetch a record that belongs to another user directly from the API rather than through the interface. If it returns data, row-level security is not doing its job. We wrote a step-by-step version of this check that you can run yourself in about five minutes.
My keys were public for months. How bad is that?
It depends entirely on which key. A publishable anon key with correct row-level security behind it is doing what it was designed to do. A service_role key, a Stripe secret key, or a database connection string is a different situation, and the assumption should be that it was found — automated scanners crawl public repositories continuously. Rotate first, then work out the exposure.
Do AI tools introduce security bugs on purpose?
No. They produce code that satisfies the request they were given, and 'make sure a different logged-in user cannot read this' is rarely part of the request. The gap is one of specification, not intent, which is also why it is so consistent.
Not sure how bad it is? That's the normal starting point.
Tell us what you built and what's worrying you. If the honest answer is that you don't need us, we'll say so.