WEB APPLICATION PENETRATION TESTING
Manual technical and business logic testing mapped to the OWASP Top 10, by an OSCP and CREST certified team.
Your web application is the part of your business an attacker can reach without ever touching your network. Every login form, API endpoint, session token, file upload, and half-forgotten admin path is exposed to anyone with a browser. A vulnerability scanner covers some of that surface, but it cannot chain a weak access control into an account takeover, and it has no knowledge of what your workflow is supposed to allow, such as an application that lets one customer approve another customer's transactions. We test web applications manually: the technical flaws a scanner only hints at, and the business logic abuse it can never see. Our team has written about the limits of web application VA scanners.
Run a preliminary website security check below.
What we test
Every finding is mapped to the OWASP Top 10 (2025), so what we report lines up with the framework your developers and auditors already know, and findings go straight into your remediation backlog. The current top-ten risk categories are:
A01:2025 Broken Access Control
Users acting outside their permissions (now includes SSRF).
A02:2025 Security Misconfiguration
Insecure defaults, exposed settings, missing hardening.
A03:2025 Software Supply Chain Failures
Risk in dependencies, build systems, and distribution.
A04:2025 Cryptographic Failures
Weak or missing cryptography exposing sensitive data.
A05:2025 Injection
Untrusted input executed by the app (SQL injection, XSS, and more).
A06:2025 Insecure Design
Security controls missing or ineffective by design.
A07:2025 Authentication Failures
Weak identity, credential, or session handling.
A08:2025 Software or Data Integrity Failures
Unverified updates/data, insecure deserialisation.
A09:2025 Security Logging & Alerting Failures
Gaps that stop you detecting or responding to an attack.
A10:2025 Mishandling of Exceptional Conditions
Improper error handling, failing open (new in 2025).
In addition to the OWASP categories, we test from the login page down to the server the application sits on:
- Authentication: credential handling, brute-force resistance, password policy, and account-recovery flows.
- Session & cookie management: token generation and entropy, expiry, fixation, and cookie attributes.
- Access control & authorisation: whether each role can reach only what it should, and nothing more.
- Data validation: how the application handles unexpected, malformed, or hostile input.
- Parameter tampering: manipulation of prices, quantities, identifiers, and hidden fields.
- Injection (various): SQL, command, LDAP, template, and other injection classes across every input.
- Cross-site scripting (XSS): reflected, stored, and DOM-based script injection.
- Cross-site request forgery (CSRF): forcing an authenticated user's browser into unintended actions.
- Insecure direct object reference (IDOR): reaching other users' records by changing an identifier.
- Use of cryptography: weak algorithms, poor key handling, and home-grown crypto.
- Clear-text transmission & sensitive information exposure: data sent, stored, or leaked without protection.
- Error & exception handling: stack traces and error messages that reveal internals to an attacker.
- Administration interface & access control: exposed or under-protected administrative functions.
- Application business logic: abuse of the workflow itself, from skipping steps to replaying transactions and bending the rules the application exists to enforce.
- Web/application server security configuration: the platform underneath the code, covering headers, services, defaults, and patch state.
How we test
Two kinds of testing run in every engagement. Technical testing targets implementation flaws such as injection, XSS, and broken session handling, which exist regardless of what the application is for. Business logic testing targets the application's own rules: what happens when someone follows the workflow in the wrong order, approves their own request, sets a negative quantity, or uses one role's access to reach another role's data. Logic flaws are invisible to scanners because nothing is technically broken. The application does exactly what it was built to do, just for the wrong person. Many of the highest-impact findings we report live there, so business logic testing runs on every engagement.
Around that, the engagement follows the same phases as every penetration test we run:
Preparation & scoping
We agree the applications, environments, and testing scenario, along with the vantage point.
You get a proposal with a fixed timeline and price.
Technical testing
Manual testing across the category checklist above, against the agreed scope.
Automated tooling assists with coverage, and every finding in the report has been validated by hand.
Business logic testing
With role credentials in hand, we walk the application's workflows the way a motivated fraudster or malicious insider would: out-of-order steps, tampered parameters, cross-role access, and abuse of the features that make the application useful.
Reporting & retest
Findings are rated by Risk Level (Critical, High, Medium, Low) with a POC and remediation guidance for each, plus an executive summary for management. After your team fixes the issues, we retest and update the report to reflect what has been closed.
How we scope it
Black-box
Simulates an external attacker with no prior knowledge of the system.
Gray-box
Gives us credentials for every user role, so we can test the business process itself, including vertical privilege escalation (a normal user reaching admin functions) and horizontal privilege escalation (one user reaching another user's data).
External
Testing from the Internet.
Internal
Testing from your intranet, for applications that never face the public.
What you get
Every report contains, at minimum:
Executive summary
The business-level risk picture, suitable for management and auditors.
Findings by Risk Level
Each vulnerability rated Critical, High, Medium, or Low and mapped to the OWASP Top 10 (2025), so remediation can be prioritised objectively.
POC for every finding
The exact steps to reproduce each finding, with requests, payloads, and screenshots.
Remediation guidance
Practical fixes for your stack.
Retest verification
Findings are re-checked after your fixes and the report is updated to reflect closed items.
Every engagement to date has produced validated findings.
Team credentials
- OSCP
- OSCE
- CREST CRT
- CREST CPSA
- GIAC GREM
Testing is performed by our in-house team, with certifications earned through hands-on practical examination. See the full list of certifications the team holds.
Our methodology follows NIST SP800-115 (Technical Guide to Information Security Testing and Assessment), aligned with the Penetration Testing Execution Standard (PTES) and OSSTMM, with findings mapped to the OWASP Top 10 (2025). Tell us during scoping what your audit needs.
Related services
Penetration test
The engagement follows the same phases as every penetration test we run.
PCI DSS penetration test
If your application sits in a payment-card environment, the web pentest feeds directly into the wider PCI DSS scope, scoped and reported the way QSAs expect.
Last reviewed: 12 Oct 2026
Web Application Penetration Test
The applications, environments and testing scenario are agreed up front, and you receive a proposal with a fixed timeline and price.
Frequently asked questions
What does a web application penetration test cover?
Every finding is mapped to the OWASP Top 10 (2025), but our coverage goes deeper than the ten headings: authentication, session and cookie management, access control, data validation, injection (SQL, command, XSS, and more), CSRF, IDOR, cryptography, error handling, administrative interfaces, business logic, and the server configuration underneath the code.
How does manual testing differ from a scanner?
A scanner reports what it recognises one request at a time. It cannot chain two weak controls into an account takeover, and it has no model of what your workflow should allow. We run tooling for coverage, then validate every issue by hand before it reaches the report.
What is the difference between black-box and gray-box testing?
What changes is how much of the application a tester can reach in the time you are paying for. Black-box starts with no credentials, so effort goes into finding a way in and the parts of the app behind a login may never be reached at all. Gray-box starts with an account for every role, which puts that time into the authenticated functionality where access-control and business-logic flaws live. Most applications are worth testing gray-box for that reason, and we will say so during scoping if yours is.
What is business logic testing?
It targets the application's own rules rather than its code: approving your own request, replaying a transaction, setting a negative quantity, reaching another role's data. Scanners miss these because nothing is technically broken, and the fix is usually a workflow change rather than a patch, so the finding goes to your product owner as often as to your developers.
Which standards do you follow?
NIST SP800-115 for how the engagement runs, PTES and OSSTMM alongside it, and the OWASP Top 10 (2025) for how findings are labelled. The split matters when an auditor asks: the first three govern method and evidence, the OWASP mapping is what lets your developers file a finding against work they already track. Applications in a payment-card environment are scoped so the same testing also answers PCI DSS Requirement 11.
From our testers
ARTICLES/7 Mar 2023
หา Path และ Endpoint จาก Wayback Machine ใน Black-box Pentest ที่เจอแต่หน้า Login
บทสนทนาระหว่าง senior pentester กับ rookie เมื่อทดสอบ web application แบบ black-box แล้วเจอแต่หน้า login ทางเลือกแบบ authenticated และ unauthenticated และการคุ้ย path จาก Wayback Machine ด้วย waybackurls
ARTICLES/7 Jun 2021
An untold story about web application vulnerability assessment
ทำไม VA scanner ที่ตั้งค่าแบบ default ถึงให้ผลไม่แม่น รวมทริคปรับการ scan ให้ผลลัพธ์ตรงขึ้น พร้อมวิธีลดความเสี่ยงที่การ scan จะไปกระทบระบบจริง
ARTICLES/7 Jun 2021
NDID และมาตรฐาน IAL/AAL จากมุมมองของ Penetration Tester
Digital ID ย้ายการยืนยันตัวตนจากเอกสารกระดาษมาอยู่บนระบบดิจิทัล บทความมองระบบนี้ด้วยสายตาคนทดสอบเจาะระบบ ว่าจุดไหนที่ผู้โจมตีจะเล็งก่อน
Tell us about your application
Tell us during scoping what your audit needs, and we will agree the scope and the scenario with you.
