Web Security Audit: Complete Guide for Companies in 2026

A web security audit is a professional technical security assessment of an HTTP/HTTPS application, run by an external team of specialists, that closes with a report documenting reproducible vulnerabilities, their impact and the recommended fix. It's not the same as an automated scanner, not the same as a code review and not the same as a functional test. A serious web audit identifies anything from authorisation flaws (IDOR/BOLA, mass assignment) to broken business logic, injections, cryptographic problems, insecure configurations and everything the current OWASP Top 10 covers.

This guide covers what a web audit really includes, when to contract one, the three approaches (white box, black box, grey box), typical scope, deliverables you should expect, realistic timelines, the compliance frameworks that require it and how to evaluate the provider before signing.

What a professional web audit includes

A well-executed web audit combines four kinds of testing:

1. Automated tests (Burp Suite Pro, OWASP ZAP, Nuclei, commercial scanners). Cover known vulnerabilities, give a fast baseline and rule out noise.
2. Manual tests (the part that separates a serious audit from the rest). The auditor explores the application as a real attacker would: chains requests, manipulates tokens, tries legitimate flows with unexpected values.
3. Business logic analysis. Where most serious bugs appear and where the scanner doesn't reach: stackable discounts that produce a negative price, transfers between accounts that break the balance, coupons that get redeemed twice, payment sequences that skip validations.
4. Audit of configurations and associated infrastructure. HTTP security headers, TLS, cookies, CORS, session storage, deployment, dependencies.

What the current OWASP Top 10 covers and any web audit should touch: broken access control (IDOR/BOLA), cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, software and data integrity, logging and monitoring failures, SSRF. Detail in OWASP Top 10 2025 business vulnerabilities.

When you need a web audit

Five scenarios where not auditing means accepting risk that's hard to justify later:

1. Before a public product launch. The first time the application gets exposed to the internet, especially when it handles personal data, payments or authentication.
2. After a significant change. Refactor of the authentication module, SSO integration, deployment of a new payment gateway, technology stack migration.
3. Recurring compliance. PCI DSS demands annual audit plus after changes. NIS2 art. 21 demands proven effectiveness of technical measures. ISO 27001:2022 control 8.29 demands testing in the lifecycle.
4. After an incident or intrusion attempt. Validate what broke, whether persistence remained and whether the applied fixes really close the vector.
5. Initial audit in a new organisation (M&A, due diligence). When you join a group, buy a company or merge platforms.

For many sectors the reasonable minimum frequency is annual, with extra audits after major changes. Sectors with specific compliance (banking under DORA, retail under PCI DSS, public sector under ENS) have mandatory frequency that the regulator defines.

Types of web audit: white box, black box and grey box

The three models change what information the auditor receives before starting, and that changes depth and cost.

Black box

The team audits without prior information. They only know the public URL. Nobody from the client gives credentials, database schema or source code.

Pros: simulates a real attacker who also lacks that information. Cons: takes longer to discover areas the client knows from inside, doesn't audit authenticated areas in depth, leaves important parts of the application effectively out of scope.

When it fits: validating perimeter and the "first barrier" of the application.

White box

The team gets credentials for every role, source code, database schema, architecture, internal documentation.

Pros: maximum depth. Finds bugs that require knowing the internal domain (subtle race conditions, complex business logic, deserialisation in specific endpoints). Cons: more expensive and longer. Can overwhelm the auditor with information if the client's team doesn't organise it.

When it fits: critical applications (banking, healthcare), new major release before production, in-house software you plan to sell to others.

Grey box

The team receives credentials for the main roles and functional description, but not source code. The intermediate model.

Pros: best quality-cost ratio. Covers most serious bugs without the extra cost of code review. Cons: blind to bugs only visible by reading the code (deserialisation in a specific function, hardcoded secrets in the repository).

When it fits: the default option in most professional web audits. Used in at least 70% of serious projects.

More detail in white-box vs black-box vs grey-box testing.

Typical scope of a web audit

What goes in and out usually gets agreed in the prior scoping. Reasonable model for a mid-sized web application:

In scope:

• The full public product URL (frontend + API endpoints it consumes).
• Every user role (anonymous, registered, premium, admin if applicable).
• Critical flows: registration, login, password recovery, payment, account management, data export.
• Main business logic (cart, transactions, internal messaging).
• HTTP headers, session management, in-transit cryptography, credential storage.
• Directly related subdomains (api.domain.com, admin.domain.com).

Usually out of scope unless explicitly agreed:

• Cloud infrastructure (AWS/Azure/GCP). That's a separate cloud pentest.
• DDoS and stress testing.
• Mobile app consuming the same API. Specific mobile audit, see mobile pentest iOS and Android.
• Social engineering and targeted phishing of employees.
• Physical pentesting of offices.

Any ambiguity gets resolved in scoping before signing. A serious provider passes you a detailed scope document with endpoints, roles and explicit exclusions.

Web audit deliverables

What you should expect at closure:

• Executive report (3-5 pages). Summary for leadership with main risks, overall posture and prioritised action plan.
• Technical report (40-200 pages depending on finding volume). For each vulnerability: description, exact HTTP request, screenshot, business impact, justified CVSS severity, fix recommendation, reference to standard (OWASP, CWE, MITRE).
• Annex with scripts and tools used, when applicable.
• Technical debrief with the development team (1-2 hours) to clarify questions.
• Retest after fixes, with differential report confirming which findings are closed.
• Audit certificate (when applicable for final client or regulator) documenting methodology, scope, dates and signatory.

If the provider doesn't deliver a technical report with reproducible HTTP requests and justified CVSS severity, that's not an audit, that's a scanner in disguise.

Realistic timelines

What a professional web audit takes, from start to delivery:

Total full cycle: 4-8 weeks from first contact to closed retest, for a mid-sized web application in grey box.

Compressed timelines (audit in 5 days) usually mean reduced depth or oversized team. Both penalise quality.

Factors that determine price

The web audit budget depends on variables identifiable before requesting a quote:

• Approach type: white box > grey box > black box in order of cost per day of the required team.
• Scope size: number of endpoints, modules, roles, third-party integrations.
• Technical complexity: elaborate business logic, custom cryptography, multi-tenant, distributed microservices raise effort.
• Target compliance: PCI DSS or pentest under DORA demand specific evidence and format that increase drafting time.
• Timelines: an audit with an aggressive deadline costs more than one planned two months ahead.
• Retest: including 1, 2 or N retests changes the final figure.

What's most useful when comparing offers is not the absolute figure but the cost per person-day of the team and the proposed duration for the same scope. Two proposals with the same final figure can hide a factor of three in real hours worked. More in penetration testing pricing in Spain.

Compliance that requires web audit

Frameworks where the web audit is required or strongly recommended:

• PCI DSS v4.0 (req. 11.4). Annual internal and external pentest plus after any significant change. Mandatory if payment is processed directly.
• NIS2 (article 21). Demonstrated effectiveness of technical measures for essential services delivered via web. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (articles 24-25). Annual operational resilience testing for financial entities. More in DORA compliance guide for financial entities 2026.
• ENS (Royal Decree 311/2022, Operational Framework). Regular technical audit for medium and high category systems in the public sector.
• ISO 27001:2022 (control 8.29). Documented security testing within the ISMS.
• GDPR (article 32). Appropriate technical measures. The audit is the standard way to evidence technical diligence.

Asking the provider to indicate in the proposal which specific framework controls the deliverable applies to simplifies the subsequent audit.

How to choose the web audit provider

Five filters:

1. Identifiable and technically active team. Names, certifications (OSCP, OSWE), references, talks, signed advisories.
2. Methodology traceable to OWASP WSTG and OWASP Top 10. Explicit reference in the proposal. If it says "proprietary methodology" with no detail, drop it.
3. Anonymised sample report. The real deliverable, not the marketing template.
4. Retest included in the original scope, not as extra.
5. Sector-fit capability. Auditing fintech, healthcare or public sector calls for different profiles.

Detail in sister guides: how to choose a penetration testing company and cybersecurity companies in Spain.

What to do after the audit

The report is the starting point, not the end of the process:

1. Triage findings by real risk. Not by isolated CVSS severity but by exploitation probability and business impact.
2. Assign fixes to sprints with owner and date. Criticals first, then highs by category (authentication, authorisation, cryptography).
3. Validate fixes with retest. The retest turns the report into a certificate usable in front of auditors.
4. Integrate prevention into the SDLC. What appeared once will appear again if the development process doesn't change. Code review with OWASP checklist, SAST/DAST in CI/CD, specific training for the development team.
5. Plan the next audit. Annual minimum or after significant changes. Year-over-year continuity speeds things up because the team learns the context.

Frequently asked questions

What's the difference between a web audit and a web pentest?

In Spanish market practice the terms get used as synonyms. Technically "audit" has a broader nuance (includes documentary review, configurations, compliance) and "pentest" focuses on the offensive simulation. A serious proposal covers both components under either of the two names. More in web application penetration testing.

Do I need an audit if I already have an automated scanner in CI/CD?

Yes. The scanner covers known signature-based vulnerabilities. It does not detect broken business logic, granular authorisation, request chains, race conditions or any bug that requires understanding the domain. The manual audit attacks exactly that gap. Combining both is the right practice: continuous scanner plus periodic manual audit.

Does the application have to be down during the audit?

No, unless otherwise agreed. A professional audit runs on the agreed environment (pre-production ideally, production if it's the only option) without affecting availability. Tests that can have impact (heavy fuzzing, exploits with probability of bringing the service down) get agreed in scope and run in windows outside critical hours.

How many vulnerabilities usually appear in the first audit?

In applications never audited before, typical findings range from 10 to 50 classified items (3-8 criticals or highs, the rest mediums and lows). Applications that have been through cycles end up with 5-15 findings in each subsequent audit, mostly mediums and lows. A perfectly clean report on the first try is very rare and, if it appears, the depth of work is worth questioning.

Is the audit enough to certify ISO 27001 or meet PCI DSS?

The audit is one of the evidence elements the certification auditor asks for, but it's not certification itself. For ISO 27001 it covers control 8.29 and brings material to the ISMS auditor. For PCI DSS v4.0 it meets requirement 11.4 if methodology and team match the criteria. The final certification is issued by the accredited entity (in Spain AENOR, BSI, Bureau Veritas, among others).

How long does it take to fix everything that appears?

Depends a lot on volume and organisation. A reasonable development team closes critical findings in 2-4 weeks, highs in 1-2 months, mediums and lows can spread across sprints over 3-6 months. What matters is prioritising well and documenting the decision when a finding gets accepted as residual risk instead of being closed.

Related resources

• Web application penetration testing: the detailed technical methodology the team applies during the audit.
• OWASP Top 10 2025 business vulnerabilities: the reference catalogue any serious audit covers.
• White-box vs black-box vs grey-box testing: how to pick the right depth.
• How to choose a penetration testing company: concrete criteria to evaluate the provider.
• Cybersecurity companies in Spain: how to choose: broader market context for the decision.
• Penetration testing pricing in Spain: cost drivers in web audit engagements.

Web audit at Secra

At Secra we run web audits against OWASP WSTG and the current OWASP Top 10, grey box by default (white box and black box available when needed), with executive report separated from technical, reproducible proof of concept per finding, justified CVSS severity, retest included and mapping to NIS2, DORA, ENS, ISO 27001 or PCI DSS as applicable. The team publishes its own research (CVE-2025-40652 and CVE-2023-3512 signed on NVD and INCIBE-CERT). If you want a concrete proposal for your application, get in touch through contact or check the detail of the web and mobile audit service.