The review
What a security review of your code and infrastructure covers
Most breaches don't start with a genius. They start with a scan: automated tools, increasingly driven by AI, that sweep the internet for an open database, a key in the code, an unpatched component or an account without multi-factor login. A security review looks for those same weaknesses in your systems first, from the inside, and tells you which ones matter.
Rather just ask someone? Talk to usIn short
A security review is a senior developer reading your code and configuration, and testing the live system, for the weaknesses attackers find first: broken access control, exposed keys, vulnerable packages, cloud misconfiguration and over-permissioned integrations. You get a report ranked by risk, with fixes. At PixelApps, a single small app starts at $495; larger reviews are fixed-price quotes.
General information, current as at November 2026, not legal advice. A review lowers risk; it can't guarantee a system won't be breached, and it isn't a certified penetration test or a compliance audit.
- What is a code and infrastructure security review?
- An expert examination of how an application is built and where it runs, aimed at finding security weaknesses before someone else does. It combines reading the source code and configuration (a white-box review) with checking the live system the way an outsider sees it. It is broader than a scan, and narrower and less formal than a certified penetration test.
How it's priced
Our prices. Fixes are always quoted separately, and you're never obliged to have us do them.
- Single small app audit $495
- Fixed price. Code, database and hosting, including the security checks, with a written report in 3 business days.
- Larger review Fixed quote
- Several apps, cloud accounts, integrations or AI agents. Scoped on a call, priced in writing before work starts.
- Fixing what we find Fixed quote
- Quoted per finding or as a short sprint, once you've read the report.
- Keeping it that way from $750 per month
- Patching, dependency updates, monitoring and an agreed block of development time each month.
What actually matters
We start with who can see and change what
Broken access control is first on the OWASP Top 10:2025 for a reason. We check that every record, file and admin action is protected on the server, not just hidden in the interface, including Supabase row-level security, Firebase rules and API endpoints the front end never calls.
Then secrets, everywhere they hide
Keys and tokens turn up in front-end bundles, environment files, Git history, CI logs and AI tool configuration. We search all of it, check which secrets are still live, and list exactly what to rotate.
Then what you didn't write
Most of a modern app is other people's packages. We review dependencies and lockfiles for known vulnerabilities and suspicious packages, and check that the build pipeline can't be used to publish or deploy something you didn't approve.
Then where it runs
Cloud and hosting accounts: who has admin, whether multi-factor login is enforced, what's publicly reachable, whether storage buckets are open, whether backups exist and have been restored, and whether anything would tell you if someone got in.
Then what it's connected to, including AI
Integrations, OAuth apps, webhooks and AI features each hold some of your access. We list what each one can read and do, and whether an AI agent could be talked into doing something it shouldn't.
Finally, a report you can act on
Each finding has a plain-English explanation, the evidence, a risk rating and a recommended fix, with the urgent items first. The report is yours to keep, share with investors or customers, and hand to whoever does the fixing.
What we'll ask for
Read-only access wherever possible. Nothing here needs you to send a password by email.
- Read access to the code repository (GitHub, GitLab or Bitbucket)
- A list of where it's hosted and what it connects to
- Read-only or auditor access to the cloud, hosting and database consoles
- A test account for each kind of user, on a staging copy if you have one
- Any past security reports, customer questionnaires or incidents
- Who to contact if we find something urgent mid-review
Where we'd point you elsewhere
If a customer contract, insurer, tender or regulator specifically requires a certified penetration test or a SOC 2 or ISO 27001 audit, our review isn't a substitute. Engage an accredited provider for that, and use us to find and fix the obvious issues first so you aren't paying a specialist to report them. And if you need around-the-clock monitoring, that's a managed security provider's job, not ours.
Tell us what you'd like checked
Describe what you run and what's worrying you. We'll suggest a sensible scope and a fixed price, or tell you plainly if a different kind of specialist would serve you better.
Common questions
A single small app is 3 business days from access to report. A larger review of several apps, cloud accounts and integrations usually takes one to three weeks, depending on scope. We agree the timeline with the fixed price before starting.
Read-only access to code and configuration, plus test accounts on a staging copy, covers most of a review. Where we need to look at production, it's read-only and agreed in writing first. We never run destructive tests against a live system, and we don't need anyone's personal password.
It will make it meaningfully harder to break into, by finding and fixing the weaknesses attackers look for first. No honest reviewer can promise a system is secure or won't be breached; new vulnerabilities appear every week. That's why the report also covers how to keep things patched and how you'd notice a problem.
Yes, that's most of what we review. Inherited codebases and apps built with Lovable, Bolt, v0, Replit, Cursor or Claude Code all get the same review. The report is written so that the original developer, your own team or us can act on it.
Both. Small businesses usually want one app or site checked. Startups and scaleups often want a review before a funding round, an enterprise deal or a launch, sometimes alongside our technical due diligence work.
See it working
Software we'd build, running with a fictional business and sample data. Use it, then decide.
Also worth a look
- Security Review vs Penetration Test
- Is AI-Generated Code Secure?
- Cloud and Hosting Security: What to Check
- Already broken or stuck? Fix & rescue
Last reviewed . General information, not legal advice. Figures cited are from the sources named on each page.