A website or SaaS security audit follows a predictable path: agree the scope, list everything that is in it, check dependencies and configuration with tools, review authentication, permissions, APIs and data access by hand, record and rank what is found, then help you fix it and verify the fixes. What you get at the end is a written, prioritised list of risks and how to address them. What you do not get is a guarantee that nothing else is wrong, and any reviewer who promises one is overselling.
Key takeaways
- Scope defines value. A clear scope decides what is examined, how deeply, and what is not.
- Tools find the obvious; people find the serious. Business logic and access control need manual review.
- The report should be prioritised. Severity, evidence and a practical fix for each finding.
- Verification closes the loop. Fixes are retested, not assumed.
Audit, scan or penetration test?
| Type | What it does | Good for |
|---|---|---|
| Automated scan | Runs tools against code, dependencies or a URL | Catching known issues cheaply and often |
| Security review or audit | Examines application, configuration and code, with manual checks | Finding and prioritising real risks |
| Penetration test | Actively attempts to exploit vulnerabilities within agreed rules | Proving impact, meeting customer or compliance demands |
These overlap, and many engagements mix them. The important thing is that the scope states which you are buying.
The audit, step by step
1. Scoping and rules of engagement
The review starts by agreeing what is in scope: which applications, environments, APIs, admin areas, mobile apps, cloud accounts and third-party services. It also covers access (test accounts for each role, code repository, read access to configuration), what testing is allowed against production, and timing. A good scope says what is out of scope too, so nobody assumes coverage that does not exist.
2. Asset inventory
Next, the reviewer maps what actually exists: domains and subdomains, environments, endpoints (including ones the frontend no longer uses), background jobs, storage buckets, databases, secrets and the third-party services the app depends on. Forgotten assets, such as an old staging site with real data, are a common and serious finding on their own.
3. Automated checks
- Dependency scanning against known vulnerability databases, for example with npm audit or equivalent tools.
- Secret scanning across the codebase and its history.
- Configuration checks: security headers, TLS, cookie flags, CORS, storage bucket permissions.
- Static analysis for risky code patterns.
Automated tools produce noise as well as signal. Part of the reviewer’s job is triaging results so the report contains real, relevant issues rather than a raw export.
4. Manual review of what matters most
This is where most serious findings come from. The OWASP Web Security Testing Guide organises the areas covered, which typically include:
- Authentication: sign-up, login, password reset, multi-factor flows, session lifetime and logout.
- Authorisation: whether each role can reach only what it should, across the interface and every API. Broken access control is first on the OWASP Top 10:2025.
- APIs: authentication on every endpoint, input validation, rate limiting, and how errors are returned.
- Database access policies: for apps where the browser talks to the database directly, row-level policies are reviewed and tested with real roles, as described in Supabase’s guide to securing your API.
- Business logic: the flaws tools miss, such as applying a discount twice, skipping a payment step, or approving your own request.
- Data handling: what is stored, encrypted, logged and exposed, and to whom.
- Infrastructure and hosting configuration within scope: environment separation, secrets management, backups and access to production.
5. Recording and ranking findings
Each finding should include what was found, where, evidence or steps to reproduce it, its severity, and a recommended fix. Severity weighs how easily it could be exploited against the damage it would cause in your context. A vulnerable library in a code path you never call is less urgent than a missing permission check on an API that returns customer data.
6. The report
Expect a written report that typically contains:
- A short summary for non-technical readers: overall picture and the most important risks.
- The scope, methods and limitations of the review.
- Detailed findings with severity, evidence and recommended fixes.
- A prioritised remediation plan: what to fix now, soon, and as part of normal work.
7. Remediation and verification
You or your developers fix the findings, starting with the critical ones. The reviewer then retests to confirm each fix works and has not introduced new problems. Without verification, a report is a list of good intentions.
How to read severity ratings
Reports usually group findings into four or five levels. Labels vary between reviewers, but the meaning tends to be similar:
| Severity | Typical meaning | Usual response |
|---|---|---|
| Critical | Easy to exploit, with serious impact such as access to other customers’ data | Fix immediately, before anything else |
| High | Serious impact, but needs some conditions or effort to exploit | Fix in the current cycle |
| Medium | Limited impact or harder to exploit | Schedule into planned work |
| Low | Minor weakness or defence-in-depth improvement | Fix when the area is next changed |
| Informational | Observation or good practice, not a vulnerability | Consider |
Ask the reviewer to explain any rating you disagree with. They know the attack; you know the business context, such as whether a feature is used by customers or only by staff. Good ratings come from combining both.
When to commission an audit
- Before launching to paying customers, or opening sign-ups to the public.
- Before a large customer’s security questionnaire or procurement review.
- After a major change: new authentication, payments, permissions model or hosting.
- When taking over code you did not write, including AI-generated code.
- After a suspected incident, alongside the incident response itself.
- Periodically, for example once a year, for applications holding sensitive data.
Choosing a reviewer
Ask for a sample report with client details removed, and look at whether findings are specific, evidenced and actionable. Ask how they handle access to your systems and data, whether testing against production is included, how retesting works and what it costs, and who exactly will do the work. Be wary of fixed promises such as “we will find every vulnerability” or a report that is mostly scanner output with a logo on top.
How to prepare
- Write down what the application does, who uses it, and what data it holds.
- Prepare test accounts for every role, in a staging environment with realistic but non-sensitive data.
- Grant read access to the repository and the relevant configuration.
- List known concerns and anything that has gone wrong before.
- Name one person who can answer questions quickly during the review.
If you would like to do a first pass yourself, our practical security checklist for AI-generated code covers the issues reviews most often find in AI-built apps.
What an audit cannot do
An audit is a snapshot of the scope at a point in time. It cannot certify that no vulnerabilities exist, and it does not cover what was out of scope. Security improves most when reviews are paired with ongoing habits: dependency updates, code review, monitoring and periodic re-assessment. Frameworks such as the OWASP Application Security Verification Standard help define what “secure enough” means for your application’s level of risk.