What is a web security audit and what does it include?

By Kike Gandia · Co-Founder & CEO, OSCP

"Web security audit" is the term most companies search for when they want to know whether their site or application has exploitable vulnerabilities — and also the term many agencies use to sell a 20-minute automated scan dressed up as a serious assessment. This guide explains what a real web security audit should include, how it differs from a simple scan and from penetration testing, and what to demand before paying for one.

What a web security audit actually is

A web security audit is a technical assessment of a web application or portal — code, configuration and business logic — to identify vulnerabilities a real attacker could exploit. It's not a "best practices" checkup or a list of generic recommendations: it's the active verification of whether a specific flaw (a SQL injection, a broken access control, a poorly managed session) can be exploited in your application, with reproducible evidence for every finding. The goal isn't to score your site against a checklist — it's to answer one concrete question: if someone tries to compromise this today, what do they get?

What a serious web security audit includes

Manual testing across the OWASP Top 10: SQL injection, XSS, SSRF, IDOR, insecure deserialization and authentication flaws, each verified individually, not just flagged by signature. Business logic review: bypassing checkout or signup flows, privilege escalation between user roles, price or discount manipulation. Authentication and session management: password policies, tokens, cookies, 2FA mechanisms and their resistance to bypass. Exposed configuration: security HTTP headers, TLS/SSL, CORS, CSP and metadata leaked in error responses. If the site runs on a CMS (WordPress, Magento, PrestaShop, Drupal), a specific review of plugins, extensions and the admin panel. The result is a report with every finding classified by CVSS, backed by proof of concept (screenshots, requests/responses) and reproduction steps — not a list of theoretical risks.

Web security audit vs. automated scan

An automated scanner (Qualys, Nessus, Acunetix and similar tools) checks your application against a database of known signatures and versions: it's fast, cheap and useful as a first filter, but it doesn't understand your business logic or chain minor findings into a real attack. It won't catch that a regular user can access another user's data by changing an ID in the URL, or that two combined permissions allow privilege escalation to admin. Many cheap "web security audits" are exactly this: a scanner's output with a template on top. A real audit uses automated tooling as a starting point, but the value is in manually verifying every finding and actively hunting for what a scanner can't see.

Is it the same as web penetration testing?

In practice, when a web security audit is done with the rigor described above, it's the same process we call web penetration testing: manual assessment, controlled exploitation and verification of real impact. The naming difference is more about marketing than technique — some companies reserve "audit" for a review more focused on configuration and compliance, and "pentest" for the active intrusion exercise — but if you want real protection against an attacker, what you should demand is the same in both cases: manual testing, verified exploitation and an evidence-backed report, not an unverified list of CVEs.

How long it takes and what drives the price

A web security audit for a medium-sized application (corporate portal, e-commerce, B2B SaaS) usually takes one to three weeks, depending on the number of features, user roles and endpoints in scope. Price mainly depends on the surface being assessed (number of flows and roles) and the testing approach chosen (black, grey or white box) — not on the size of the company hiring it. You can see the full cost breakdown in our pentesting cost guide, or get an estimate with the pentesting cost calculator.

How often to repeat a web security audit

At minimum, once a year if the application doesn't change often. In practice, more frequently if you ship continuously: any significant change to authentication, payment flows or role management reintroduces risk, even if the rest of the code hasn't been touched. It's also worth repeating before a certification (ENS, ISO 27001, PCI-DSS if card payments are involved) or when an enterprise client requires it contractually — in that case, critical findings also need to be re-tested, not just reported.

FAQ

What is the difference between a web security audit and web penetration testing?

When both are done rigorously, none: manual testing, controlled exploitation and verified real impact. The difference is usually marketing — some companies use "audit" for reviews more focused on configuration and "pentest" for the active intrusion exercise — but what you should demand is the same in both cases.

Does an automated scanner like Qualys or Nessus count as a web security audit?

It works as a first filter, not as a full audit. It detects vulnerabilities known by signature or version, but doesn't understand your application's business logic: it won't see that two combined permissions allow privilege escalation, or that a checkout flow can be manipulated. A real audit uses automated scanning as a starting point and adds manual verification.

What should I demand to make sure the audit is real and not a scan in disguise?

Ask for a previous audit report (anonymized) before hiring: if it only contains findings with a known CVE and no original proof of concept, it's a scan with a template on top. A real report includes business-logic findings specific to your application, backed by reproducible evidence (screenshots, requests/responses) and CVSS classification.

How long does a typical web security audit take?

Between one and three weeks for a medium-sized application, depending on the number of roles, flows and endpoints in scope. Very large applications or those with multiple integrations may need more time; narrowly scoped engagements (a single critical flow) can be completed in a few days.

Do you need access to the application source code?

Not for a black-box or grey-box audit, which are the most common: in black box we work without credentials, like an external attacker; in grey box we use standard user credentials to assess access control. Code access (white box) is optional and allows a more exhaustive analysis, but it's not a requirement for the audit to be real.

Related service

web penetration testing for businesses

Sources

Request a web security audit