Web app vulnerability assessment to OWASP WSTG and ASVS
We test authentication, sessions, access control, business logic, APIs and injection flaws, manually and with scanners. You receive an executive summary and a technical report with CVSS scores and evidence for every finding.
What types of web application testing do we offer?
DAST
Automated scanning with two scanners and manual review.
Quick
DAST: a web app vulnerability assessment that goes beyond the scan
We add manual work to keep the results accurate:
We train each scanner on your application so that it covers the critical functions and skips the irrelevant ones.
A second scanner re-checks the results to reduce false negatives.
The final report combines the output of both scanners with our manual analysis and validation of the findings.
Comprehensive pentest
According to OWASP WSTG.
optimal
Web application pentest
We test against the OWASP Web Security Testing Guide (WSTG), a widely used reference for web application testing, and draw on PTES and NIST SP 800-115. Scanner output is checked by hand and every finding is confirmed before it goes into the report, so you receive proven issues with evidence, not a list of scanner warnings.
Full depth
Full application security verification to OWASP ASVS.
Comprehensive
Web application security assessment to the OWASP Application Security Verification Standard (ASVS)
Choose ASVS when the application needs the highest level of assurance. It goes further than a standard penetration test: the verification works through the ASVS requirements for the whole application, not only the parts reachable from outside.
Black-box testing alone has known limits in finding critical flaws. For ASVS we work in hybrid mode, with access to the source code and to your developers during the assessment. Automated tools catch common issues, but many ASVS controls can only be verified by a person. A hybrid test also lets us trace a flaw from the interface down to the code and agree the fix with the people who wrote it.
The review covers architecture, design, configuration, authentication, access control, input validation, output encoding and sanitization, and error handling. Each area is checked against the matching ASVS requirements, and the findings are mapped to them.
Tell us what you are building and we will propose the right depth and scope.
How this maps to standards
ISO/IEC 27001:2022 — Annex A controls 8.8 and 8.26 cover technical vulnerability management and secure development. The standard does not name penetration testing outright — it is simply the usual way organizations show these controls actually work.
SOC 2 Type II: Not a formal requirement. In practice auditors ask for testing performed inside the audit period, because vulnerability management is otherwise hard to evidence.
PCI DSS v4.0.1: Requirements 11.4.2 and 11.4.3 call for internal and external penetration testing at least once every 12 months and after any significant upgrade or change. This one is an obligation, not a recommendation.
OSFI B-13: expects federally regulated financial institutions to test regularly using an intelligence-led approach, with penetration testing and red teaming named as examples. It is a guideline, not a statute. If you supply software to a federally regulated institution, expect the requirement to reach you through their third-party contract.
CCSPA (Bill C-8): received Royal Assent on June 15, 2026, but it is not yet in force and will apply only to designated operators, and no classes are designated yet. It will require a cyber security program, and an assessment is a practical way to check how well your measures work before then.
Executive report
Findings and business impact, written without jargon for management and the board. Each issue is stated in terms of what it puts at risk, not how it works technically.
Technical data
A detailed technical description of every finding: affected systems, CVSS severity, reproducible evidence and the conditions required to exploit it. Written for your engineering team.
Work reports
What was tested, when, and by which method. We test to the OWASP Web Security Testing Guide and ASVS, PTES and NIST SP 800-115, and we state the scope explicitly, including what was deliberately left out.
Navigator
A project database for navigating the results rather than a flat PDF. Findings can be filtered by severity, affected system and owner, which is what makes remediation trackable across a team.
Risk reports
Attack scenarios with screenshots and reproducible evidence. Every finding carries a CVSS score and a plain statement of the business consequence if it is exploited.
Remediation guidance
A specific fix for each finding, not a generic recommendation. Where several findings share a root cause we say so: patterns matter more than point fixes.
Retest and evidence
After you remediate, one retest of the fixed findings within 12 months is included. It confirms the issues are actually closed and gives ISO 27001 and PCI DSS auditors the evidence they ask for.
Team portfolio
Our certificates
FAQ
How often should we run a web application security assessment or website security audit?
What is the difference between a vulnerability scan and a penetration test?
Can web application security testing affect our live application?
How do we prioritize which vulnerabilities to fix first?
Is automated web security testing enough on its own?
How do we handle vulnerabilities in third-party components used by our web application?
Where to start?
Common questions about the assessment
How long does a web application penetration test take?
A web application penetration test usually takes one to three weeks, two on average. The exact time depends on the size and complexity of the application. Send us a description of it and we will give you a more accurate estimate.
What affects the cost of a web application penetration test?
The cost depends on the size and complexity of the application, the number of functions to be tested, and the depth of testing: DAST, a WSTG penetration test or a full ASVS verification.
A static website or a simple blog needs far less testing effort than a large e-commerce platform or a banking system with a complex architecture, several user roles, third-party integrations and sensitive transactions. Every additional role, integration and API adds to the scope that has to be tested.
We prepare the calculation once you describe the task: the application, its main functions, user roles, the depth of testing you need and whether testing will run on production or on a copy of it. We do not give a figure without that description.
Which methodology do we use?
OWASP Web Security Testing Guide (https://owasp.org/www-project-web-security-testing-guide/), used for comprehensive penetration testing of web applications.
OWASP Application Security Verification Standard (https://owasp.org/www-project-application-security-verification-standard/), used for full application security verification of web applications.
What are the stages of the project?
Sign the contract and NDA
Approve the test plan and methodology.
Passive information gathering and documentation study.
Active reconnaissance.
Finding vulnerabilities (automated scanning and manual testing).
Verification of each vulnerability.
Risk assessment, threat profiling, report writing.
Report presentation, then a retest once the findings are fixed.
How do you keep testing safe for our environment?
Our goal is to find weaknesses, not to cause an outage. Testing is designed not to disrupt your service, but some checks do push a system beyond its normal operating limits, so we agree the approach with you before we start. For production and critical systems we apply the following controls:
Risky actions such as vulnerability scanning and exploitation take place only in a window agreed with you, for example at a weekend or at night, to reduce the risk for your customers.
Manual checks are done carefully and scanners are configured in safe mode so that they do not overload your systems.
We agree an incident escalation procedure with you in advance, so you can respond promptly if an incident occurs. Incidents are rare, but we plan for them.
Make sure your system backups are current before testing starts.
Another option is testing in an environment identical to production.
What tools do we use?
We use both commercial and free tools for scanning, research and analysis, combined with manual testing and searches in public exploit and vulnerability databases.
Web scanners: Burp Suite and Acunetix.
Network scanners: Nexpose and Nessus.
All tools in the Kali Linux distribution, including Nmap and Metasploit.
Exploits from public databases such as ExploitDatabase, CVE Details, 0day.today and GitHub.
Custom-built tools and exploits.
Do you perform automated testing or manual testing?
A penetration test is not just vulnerability scanning: much of the work is manual. Scan results feed the manual checks, and the scanner is one tool among several.
We also offer vulnerability scanning as a separate, simpler service.
To reduce false negatives in the automated phase, we double-check the results with a second scanner.
You can copy our materials only after making sure that your services are safe.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.