OWASP WSTG · ASVS · CVSS 4.0 · PCI DSS · ISO 27001 · ENS · NIS2 · DORA
Web application security audit
Manual and automated audit of your web application. OWASP WSTG methodology, ASVS verification, broad coverage and human depth in business logic. Each finding with evidence, CVSS 4.0 severity and remediation prioritised by real risk, not by theoretical score. Evidence built to pass external audit.
Executive summary
A web audit done properly combines four things: broad coverage guided by OWASP WSTG, human depth in business logic that no scanner detects, technical evidence sufficient for an external auditor (PCI QSA, ISO certifier, ENS body) to accept the report, and a remediation plan prioritised by real risk taking into account exploitability and exposure, not by theoretical CVSS.
At Hard2bit typical projects close in 7 to 40 working days depending on complexity, with immediate notification of critical findings during execution and retesting included in scope. The report is delivered ready to support external audit: index by OWASP family, prioritised matrix, signed evidence with timestamps, separate executive report for the board.
Wide coverage + depth
Full OWASP WSTG + ASVS L2/L3 + business logic + APIs. Not a scan: a pentester with time and method.
Auditor-ready evidence
Designed to pass external audit: PCI QSA, ISO 27001 certifier, ENS auditor, NIS2/DORA requirement.
Useful remediation
Findings prioritised by real risk (exploitability, exposure, business impact), not just by CVSS score.
What we cover in a web audit
Scope adapts to each application, but the technical baseline is always the same. We cover the OWASP Web Security Testing Guide as coverage guide, ASVS L2 or L3 depending on criticality as verification criteria, and sector-specific elements when applicable: PCI DSS for payment environments, ENS High criteria for public sector, DORA requirements for financial entities, customer-specific controls when additional sector regulation applies.
Authentication and session
Password recovery, MFA, login bypass, session fixation, weak JWTs, client-side OAuth, SSO/SAML, expiration, regeneration after auth, lockout and user enumeration.
Access control
IDOR (Insecure Direct Object Reference), vertical and horizontal escalation, role bypass, resource access control, multi-tenant: that customer A cannot access customer B's data even with predictable IDs.
Injection
SQL, NoSQL (Mongo, DynamoDB), OS commands, LDAP, XPath, templates (SSTI: Jinja, Twig, Velocity), expressions (EL, OGNL), insecure deserialisation (Java, .NET, PHP, Python).
XSS and SSRF
Reflected, stored, DOM-based, blind. Classic and blind SSRF, abuse of cloud metadata (IMDS), pivot to internal infrastructure, redirect to internal non-exposed services.
Business logic
Abuse of legitimate flows: approvals without permission, race conditions, price manipulation at checkout, limit bypass, chains impossible by design.
Data exposure
Sensitive data in unnecessary responses, verbose error messages with stack trace, headers revealing stack, public repos with secrets, accessible config files.
Associated APIs
OWASP API Top 10: BOLA (object-level), BOPLA (property-level), BFLA (function-level), mass exposure, missing rate limiting, endpoint abuse.
File handling
Upload without real type validation, path traversal, system file overwrite, execution of uploaded files, double-extension abuse, ZIP slip, SVG with JavaScript.
Server configuration
Security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy), misconfigured CORS, cookies without Secure/HttpOnly/SameSite, banners revealing version, unnecessary HTTP methods.
Applied cryptography
Weak algorithms (MD5, SHA-1), predictable token generation, misconfigured TLS, expired certificates, secrets in localStorage, reused IVs.
Anti-bot and abuse defence
Rate limiting, CAPTCHA, credential stuffing prevention, account takeover prevention, anomaly detection where applicable.
Client-side and JavaScript
Validations living only client-side, secrets embedded in bundles, sensitive sources in localStorage/sessionStorage, insecure postMessage, poorly validated DOM events.
Anatomy of a critical finding
So you see what we mean by audit done properly, this is the technical pattern of a real critical finding, anonymised. An IDOR with tenant bypass on a mid-sized B2B SaaS platform. The pattern repeats in variants across many products.
Discovery
Pattern detected
Endpoint GET /api/v2/exports/{exportId}/download
served a file with a temporary signed URL. The signature was generated on the
exportId, not on the tenantId+exportId pair. By iterating adjacent exportIds (IDs were
sequential), exports from other tenants could be downloaded without re-signing. The
frontend filtered by tenant but the backend did not validate that the exportId
belonged to the authenticated user's tenant.
Severity
CVSS 4.0 = 9.3 (Critical)
AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N. Network access, low complexity, requires a valid account in any tenant. Impact: high confidentiality (data from any SaaS customer), integrity and availability unaffected. But real risk is not measured by CVSS alone: the exports contained personal data protected under GDPR, raising regulatory impact to a notification to the supervisor within 72 hours if exploitation was confirmed.
Evidence
Proof without mass exploitation
Demonstration with 2 test accounts created in different tenants belonging to the customer itself. Capture of authenticated request/response from tenant A downloading tenant B's export. No real customer data touched in production. The audit documents the pattern, not the extraction of end-customer data. Basic ethics.
Remediation
Two-layer
Immediate (8 hours): add validation tenantId == session.tenantId in
the endpoint handler. Medium-term (2 weeks): generate signed URLs that include the
tenantId in the HMAC payload, so the signature is invalidated if the exportId is
swapped for another tenant's. Long-term: review all resource-by-ID endpoints looking
for the same pattern. Three more endpoints with the same defect were found.
Anonymised technical case based on real patterns from the B2B SaaS sector. Sector, magnitudes and names altered; the technical pattern and remediation mechanics keep fidelity to the original. No public NDAs, no customer name.
When it fits and when it does not
Strong fit
When it makes sense
- Application going to production for the first time or releasing a major version
- Your customer or auditor requires evidence (PCI DSS, ENS High, ISO 27001, NIS2, enterprise contract)
- Suspected leak, incident or anomaly without clear diagnosis
- Change of development provider and you want a baseline before inheriting
- Multi-tenant SaaS scaling and needing isolation validation
- Product with payment module, sensitive data or critical approval flow
- Platform with public APIs or APIs consumed by third parties (DORA, NIS2)
- Application going to handle health, financial or minors' data
Weaker fit
When it is not the first move
- Application less than 6 months in production with no real traffic: let it mature first
- Architecture is not stable yet: any finding will change in the next release
- The problem is not technical but process (no code review, secrets in repos): start with source code audit
- You need continuous monitoring, not point-in-time: better fit with attack surface management
- You have suffered a specific incident and need containment and forensic analysis, not audit: incident response
- You are in design phase and want to anticipate threats: better a threat modeling first
How we deliver
Four real phases, no theoretical steps. The customer knows critical findings before the audit ends, not in a surprise delivery at the end. This changes the real cost of the project for the customer: remediation can start while auditing continues.
1. Technical walkthrough (1-2 days)
Session with the application owner, user profiling, agreed scope, test window, source IPs, communication plan with IT. If there is a WAF, we decide whether to leave it active (realistic audit) or disable it during the window (maximum coverage). If there is an in-house or managed SOC, we pre-notify them to avoid false positives in their workflow.
2. Manual and automated audit (60-80% of the time)
Combination of Burp Suite Pro, OWASP ZAP, custom tools and manual work. Critical findings are notified to the customer immediately through the agreed channel (not held for the final report). Auditing is not scanning: it is a pentester thinking like an attacker with time and method. We document every test executed, not just the findings, so the external auditor sees real coverage.
3. Documentation and verification
Each finding with description, evidence (screenshots, request/response, proof of concept), CVSS 4.0, business criticality, real risk considered and recommendation. We verify each finding twice to avoid false positives in the executive report. The executive report is written without technical jargon so it serves the board or management.
4. Closing and retesting
90-minute session with IT and development to discuss findings, real priority and remediation plan. If the customer needs it, retesting at 4-8 weeks to certify that the corrections work. This is what external auditors or regulated customers usually request: the report is not enough, there needs to be a second pass that closes the cycle.
What the documentation package includes
Five pieces that travel together at project close. Designed so the customer can present the material to external auditor, certifier or final customer without additional adaptation work.
1. Technical report
Each finding with description, evidence (screenshots + request/response + exploit), CVSS 4.0, business criticality, exploitation conditions, remediation recommendation and validation proof.
2. Executive report
2-3 pages for the board without technical jargon. Critical findings in business terms, aggregate risk, action plan and timelines. Board-ready.
3. Prioritised matrix
Table with all findings ordered by real risk (CVSS + exposure + exploitability + business impact + remediation effort). Practical action list for development.
4. Evidence repository
ZIP pack with all evidence signed with timestamps, file hashes, logs of the tests performed. For external auditor or regulated customer.
5. Closing session
90 minutes remote or onsite with IT and development. Discussion of findings, priority, remediation plan. Q&A with the audit team.
Extra: retesting
If contracted, second pass at 4-8 weeks to certify that corrections work. Verification letter signed for external auditor.
Sector adaptation
Standard scope stays the same, but each sector weighs certain areas more heavily and carries specific regulatory obligations. We adjust the focus without reinventing the methodology.
B2B SaaS and tech product
Heavy focus on multi-tenant isolation, token and API key management, OAuth, BOLA and object-level authorisation. High demand for evidence to respond to enterprise customer security questionnaires. Compatible with SOC 2 if applicable.
Fintech and financial entities
Focus on payment modules (PCI DSS 11.4.3), API security (DORA art. 24-27), approval flows, race conditions in transfers, fraud prevention. Requires coordination with in-house or managed SOC.
Healthcare
Focus on health data exposure (GDPR art. 9), audit of access logs to clinical records, access control by medical/administrative role, integrations with HL7/FHIR. If ENS High applies (essential healthcare operators), it includes op.exp.5.
Public sector
Focus on ENS High or Medium compliance according to system categorisation, WCAG accessibility when applicable, identity control with national e-ID and digital certificates, protection of classified information by law.
Retail and e-commerce
Focus on payment modules (PCI DSS), fraud prevention, coupon and discount abuse, malicious scraping, cart logic (price manipulation), concurrent stock management.
Industry and OT with web interface
Focus on management applications connecting to plant (MES, web SCADA), access control, logical segmentation between IT and OT, audit of commands that may affect the industrial process.
Regulatory fit
Web application security auditing is directly or indirectly required by almost every framework that applies to organisations in Spain and the EU. The technical report is delivered ready to pass external audit in any of them.
| Framework | Reference | What it requires and how we cover it |
|---|---|---|
| PCI DSS v4.0.1 | Req. 11.4.3 | Pentest of applications touching the CDE, annual and after significant changes. Technical report + verifiable remediation. PCI QSA-ready. |
| ISO 27001:2022 | A.8.29 / A.8.8 | Security testing in the development cycle and technical vulnerability management. Traceable evidence for certification. |
| ENS (High) | op.exp.5 | Periodic technical security testing with documentation of findings and remediation. Suitable for ENS audit by accredited body. |
| NIS2 | Art. 21.2.f | Policies and procedures to assess the effectiveness of risk management measures. Documented periodicity. |
| DORA | Art. 24-27 | Digital resilience testing programme, including testing of critical applications. Suitable for supervisor inspection. |
| GDPR | Art. 32.1.d | Procedure for regular verification, evaluation and assessment of the effectiveness of technical and organisational measures. Especially relevant if special category data is processed (art. 9). |
What we usually do and others do not
Not marketing, practices that take time and that we rarely see in competition reports. If your audit does not include these points, you deserve to ask why.
Immediate notification of critical findings
If we find a critical finding on day 3 of a 15-day audit, we notify you that day. We do not wait for the final report so you lose two more weeks of exposure.
Retesting included in the proposal
The price covers a second verification pass at 4-8 weeks after remediation. It is what your external auditor will ask for; we give it to you with no extra cost.
Remediation examples, not just description
Each finding comes with at least one concrete actionable recommendation (corrected code snippet, exact configuration, recommended library). The opposite of 'apply suitable controls'.
Testing with your WAF active (not only without it)
Too many reports disable WAF and report findings your WAF already blocks. We do both: realistic with WAF + maximum coverage without WAF in an agreed window.
Closing session with development, not just security
Findings are remediated by the development team. If we only speak with the CISO, information is lost in translation. We sit the pentester with the dev team.
Signed evidence repository
ZIP with timestamps, hashes, logs of tests. So your external auditor does not need to trust your word: there is verifiable, reproducible material.
Objections we hear and how we answer them
«We already have an internal pentest team, we do not need external»
Internal pentesting is good and necessary, but it has three limitations: the team knows the application too well (does not think like an external attacker), is under product-team pressure that can soften findings, and almost never produces evidence valid for an external auditor (who does not accept a report signed by the organisation itself). Both approaches complement each other; neither replaces the other.
«It is expensive. Is it worth it?»
It depends on the cost of an incident. An IDOR exploited in multi-tenant SaaS leaking personal data means: notification to the supervisor (potential fine of 4% of revenue), loss of enterprise customers for contractual breach, DFIR cost (€15-50k), urgent remediation cost (€40-80k), reputational cost (incalculable). An audit costing €15-25k that prevents this is the most profitable investment you will make this year.
«We have no time to take the application down»
No need to take it down. The audit runs in production with a communication plan with IT, agreed source IPs and exclusion of destructive tests. Or it runs in staging with representative data. What does need to happen: someone technical from the customer available for urgent questions during the window, no more than 4-6 hours spread across the project.
«Our application is very complex, I doubt you understand it in depth»
The technical walkthrough up front (1-2 days) is designed exactly for that. If after the walkthrough we think the scope exceeds what we can do well in the time available, we tell you honestly and propose splitting into two projects or reducing scope. What we do not do: promise full coverage of a huge application in 5 days to close the sale.
«We had an audit 2 years ago, it hasn't changed that much»
OWASP Top 10 has changed (2017→2021→new one in preparation). OWASP API Top 10 is new (2019, 2023). CVSS moved from 3.1 to 4.0. The threat from non-human identities and supply chain has exploded in 2024-2025. If your application is 2 years unaudited, the catalogue of things to look at has changed more than your application.
«We just want to comply, not find anything»
We understand but it is not our target. If all you need is a check-the-box for an auditor without actual findings, there are providers that do that. We do not. Our report finds things; the ones found you will have to remediate. If that is problematic for your organisation, better make it explicit before signing.
How we measure the quality of our audits
Internally we measure projects against five indicators, benchmarked against our own historic baseline. We do not publish the figures because they vary a lot per project, but we share them in the closing session so your team can see how your project compares to the internal standard.
Real WSTG coverage
Percentage of OWASP WSTG tests executed in the project. We aim for 85%+ on standard audits.
Critical/high ratio
Proportion of critical and high findings against total. Depth indicator: an audit with no criticals in a large application usually means insufficient coverage.
False positives in report
Percentage of findings rejected by the customer after verification. Target: <3%. If above 10%, the team reviews methodology.
Mean time to critical notification
Hours from detection of a critical finding to notification to customer. Target: <8 working hours. Usually under 4h.
Findings per auditor day
Team productivity. Useful to detect if an audit is going below expected depth and warrants reassignment.
Retest closed rate
Percentage of findings the customer actually closes on retest. Indicator of recommendation quality: if they cannot be applied, the recommendations were poor.
Common mistakes when buying a web audit
- Asking for the lowest price and accepting a 3-day audit. What you get is a disguised automated scan, no business logic, no evidence useful to an external auditor.
- Not giving access to an authenticated user. Without session, the auditor only tests 10% of the application (the public part). 90% of risk lives behind the login.
- Hiring pentest right before going to production and trying to remediate everything in 48 hours. The audit reveals work not on the roadmap; plan a realistic remediation window.
- Confusing audit with code review. They are complementary: the audit tests behaviour from outside; code review finds flaws invisible from outside (defective logic, hardcoded secrets, vulnerable dependencies).
- Leaving the WAF silent during the entire audit. That falsifies coverage. Better: WAF active for realistic audit + window without WAF for maximum coverage on serious findings.
- Not retesting after remediation. If there is no second pass verifying corrections, the report is worthless to a regulatory auditor.
- Confusing high CVSS with high priority. A CVSS 9 with no real exposure (endpoint only reachable from managed internal network) may be less urgent than a CVSS 6 with trivial exploitation in production.
- Asking only for the executive report. Without the technical report your team cannot remediate and your external auditor does not accept the material as evidence.
Quick glossary of audit jargon
Terms that appear in web audit reports and that are worth having clear before starting.
OWASP WSTG
Web Security Testing Guide. Coverage standard for web application pentest maintained by OWASP.
OWASP ASVS
Application Security Verification Standard. Verifiable criteria by levels (L1, L2, L3) to audit application security.
OWASP Top 10
Ranking of the 10 most critical vulnerability categories in web applications. 2021 version; new one in preparation.
OWASP API Top 10
Equivalent version for APIs. Updated in 2023. Includes BOLA, BFLA, BOPLA, etc.
IDOR
Insecure Direct Object Reference. Access to resources by changing an ID in URL/payload without backend validating ownership.
SSRF
Server-Side Request Forgery. Forcing the server to make requests to internal non-exposed resources (including cloud metadata).
BOLA / BFLA / BOPLA
Broken Object / Function / Property Level Authorisation. OWASP API Top 10 categories.
CVSS 4.0
Common Vulnerability Scoring System v4. Standard criticality scoring system. Replaces CVSS 3.1.
SAST / DAST
Static / Dynamic Application Security Testing. Static analysis (on code) or dynamic (on the running app).
WAF
Web Application Firewall. Filtering layer between internet and the application; blocks known attacks by pattern matching.
CDE (PCI DSS)
Cardholder Data Environment. Set of systems, networks and processes touching card data. Requires periodic pentest.
SBOM
Software Bill of Materials. Inventory of software components and dependencies. Increasingly required by NIS2/DORA.
Related services at Hard2bit
Web application auditing fits in a broader programme. These are the services that most often combine with it in real projects.
Pentesting
Parent service. Web is one of the disciplines we cover within enterprise pentesting.
View →
API security audit
If your API is the central piece (SaaS, fintech, B2B integrations), dedicated pentest covering OWASP API Top 10.
View →
Source code security audit
Complementary to web: finds flaws invisible from outside (logic, secrets, dependencies).
View →
Non-human identities
Tokens, OAuth, service accounts, API keys: the other 50% of modern application risk.
View →
Hardening
After the audit, strengthen the base the application runs on: OS, server, headers, configuration.
View →
Integral audit
When beyond web there is infrastructure, identity, cloud and processes: a single project.
View →
Attack surface management
Continuous monitoring after the point-in-time audit. So the next release does not introduce regressions.
View →
Red team
When beyond technical audit you want to validate defensive team's detection and response capability.
View →
Incident response
If the audit reveals findings pointing to active compromise, immediate escalation to response team.
View →
Frequently asked questions
What is the difference between manual auditing and running a DAST scanner?
A DAST scanner detects known patterns in minutes at low cost: outdated libraries, weak configurations, catalogued vulnerabilities like reflected XSS or classic SQL injection. What a scanner will never find is what brings real value: business logic flaws (a user approving their own invoices, race conditions in transfers, price manipulation at checkout), chains of low-severity findings that produce critical impact, role bypass specific to your data model, abuse of legitimate flows. In real audits, 30-60% of critical findings require human analysis and never appear in any scanner. That is why we combine both: the scanner covers the wide surface, the human auditor goes deep where there is real business risk.
What methodology do you follow?
Four normative references structure the work: OWASP Web Security Testing Guide (WSTG) as coverage baseline, OWASP ASVS L2 or L3 depending on criticality as verification criteria, OWASP Top 10 as minimum check, and elements of PTES and NIST SP 800-115 for reporting and ethics. The standard scope includes authentication, session management, vertical and horizontal access control, SQL/NoSQL/command/LDAP/SSTI injection, XSS, SSRF, insecure deserialisation, data exposure, business logic, file management, server configuration, and the associated APIs. For B2B SaaS we add tenant isolation testing (that customer A cannot access customer B's data). For PCI DSS environments, the standard's requirements drive a specific checklist.
How long does a typical web audit take and how much does it cost?
A medium-sized web application (5-15 relevant endpoints, 2-3 user profiles, standard authentication, no especially complex business logic) is audited in 7-15 working days with 1-2 auditors. Indicative cost in Spain: €8,000-20,000. Complex applications with multi-tenant, critical integrations, dense business logic, payment modules or regulated flows take 20-40 days and €25-50k. To avoid surprises we always ask for access to the application before quoting firmly; a 30-minute walkthrough changes the estimate more than any written brief. What we do not do: quote blindly in an email.
Do you need a staging environment or can you audit production?
We prefer staging with representative data (anonymised if it comes from real production). Production is feasible but requires agreed window, source IPs, WAF/CDN coverage, communication plan with IT and exclusion of destructive tests (DoS, mass modifications, real account resets). In PCI DSS, ENS High or NIS2 environments, production auditing is documented as a controlled test with timestamps, to prevent your own security team from responding as if it were a real incident. If you have an in-house or managed SOC, we pre-notify them to avoid generating false positives in their workflow.
What deliverables do we get at the end of the project?
Five pieces: (1) Technical report with each finding described, evidence with screenshots and request/response, CVSS 4.0 criticality + business criticality, remediation recommendation; (2) Executive report of 2-3 pages for the board without jargon; (3) Matrix prioritised by real risk, not just CVSS, considering exposure and exploitability; (4) Signed evidence repository with timestamps for regulatory audit; (5) Closing session with IT and development to discuss findings and remediation plan. If the customer needs it, retesting is included in scope to certify that the corrections are effective. The deliverables are designed to serve both the technical team and the external auditor (PCI QSA, ISO certifier, ENS auditor).
Does it count as evidence for PCI DSS, ISO 27001, ENS or NIS2?
Yes, when properly documented. PCI DSS v4 (requirement 11.4.3) mandates pentest of applications that touch the CDE, annually and after significant changes. ENS High category (op.exp.5) requires periodic technical security testing. ISO 27001:2022 (A.8.29) requires security testing in the development cycle. NIS2 (article 21.2.f) requires policies and procedures to evaluate the effectiveness of risk management measures. DORA (articles 24-27) regulates digital resilience testing. The technical report + executive report + remediation matrix with timestamps meets the documentary requirements of all five frameworks. If your QSA or auditor asks for something extra, we add it without charging more: the document is delivered to pass external audit.
Do you only audit the application or also the API that supports it?
If the scope includes an API, we audit it as part of the same project: most critical modern findings are in the API, not the UI. The application is the façade; the API is where the business logic lives and where an attacker finds IDOR, broken object/function-level authorisation (BOLA/BOPLA), mass property exposure, etc. For customers who need specific API focus (by volume, complexity or because the API is consumed from several client applications or mobile), we have a dedicated API security audit service covering the full OWASP API Top 10. Most engagements take both services or one with combined scope.
We have multiple microservices and APIs. How do you audit that?
We start with an architecture session to understand the graph: which microservices exist, how they authenticate to each other, which APIs are public vs internal, which service accounts exist. We audit in layers: public frontend, gateway/BFF, internal microservices, service-to-service authentication (mTLS, JWT, OAuth client credentials), service accounts and secrets. For microservices we always add non-human identities security review, which is where most lateral chain compromises have been seen in 2024-2025. If the architecture is very distributed, we suggest splitting into two projects so each is done with real depth.
What do you do if you find something critical during the audit?
Immediate notification through a previously agreed channel (encrypted email, Signal, phone call). We do not wait for the final report. The customer receives the finding with description, evidence, estimated impact and temporary containment recommendation. If the customer requests it, we help coordinate urgent remediation with their development team. The difference between 'we report at final delivery' and 'we report on detection' is weeks of avoidable exposure. When a finding is critical severity with trivial exploitation, there is no point in keeping it for two weeks.
How does an engagement start at Hard2bit?
We start with a 30-minute call to understand the application, scope, user profiles, the moment in the cycle (release, post-incident, regulatory requirement) and the customer's goal. If it makes sense, we schedule a 1-hour technical walkthrough with the application owner. After that we issue a firm proposal in 48-72 hours: scope, window, assigned team, deliverables and closed price. No commitments until signature. If after the walkthrough we believe what you need is not a web audit but source code, API or a continuous attack surface programme, we tell you honestly and redirect to the right service.
Got an application that needs an audit?
30-minute call to understand scope, user profiles and the moment in the cycle. If it makes sense, firm proposal in 48-72 hours: closed scope, assigned team, deliverables and price. No commitments until signature.