Imagine the situation. A team has shipped a new customer portal. The developers ran dozens of code reviews, DevOps stood up a WAF and monitoring, QA ran regression on every button. The release went smoothly, the metrics are green, and Slack is full of celebration emojis.
Two weeks later, someone with no authorization accesses the personal data of several thousand users. Not through a zero-day, not by bypassing the WAF with some exotic payload, but simply changing id=1245 to id=1246 in the URL, and the application politely handed over someone else's profile.
This is not a hypothetical story. It is one of the most common scenarios behind real incidents, and it has a specific name: Insecure Direct Object Reference (IDOR). After years of working with in-depth incident analysis, I can say with confidence that companies fall victim more often not because of a "Hollywood" zero-day exploit, but because of a plain flaw in authorization logic that nobody noticed, because it breaks no test and triggers no correlation rule.
Web application penetration testing exists precisely to find things like this before someone else does. This article covers in detail what it is, what methodology it follows, which vulnerabilities it looks for, and exactly what you get as a result.
What Is Web App Pentesting (and What It Isn’t)
Web application penetration testing is a controlled, authorized attempt to "break" your application the way a real attacker would: to find vulnerabilities, chain them into an exploitable sequence and demonstrate real business impact rather than just compile a list of theoretical weaknesses.
The key word here is authorized, in other words legitimate and confirmed. A pentester works within a clearly defined scope with written permission (rules of engagement), and the goal is not to cause harm but to show that harm could have been caused and exactly how to close the gap.
It is worth separating two concepts right away, because they get confused constantly: Vulnerability Assessment and Penetration Testing.
Vulnerability Assessment vs Penetration Testing
Vulnerability Assessment (vulnerability scanning) is an automated process. A scanner (Nessus, Qualys, Burp Scanner and so on) walks through the application, compares server responses against a database of known signatures and patterns, and produces a list of potential problems. It is fast, cheap, and scales well. But a scanner does not understand business logic. It does not know that user A should not see user B's invoice. It only sees an HTTP 200 and valid JSON, and to the scanner that means "all good."
Penetration Testing is manual work done by a human (or, as I will show at the end, a human together with AI agents) who thinks like an attacker. A pentester takes the scan results as a starting point, then investigates the application's logic, authorization chains, session state, and API behavior, and tries to prove exploitability rather than just record an anomaly.
A simple example of the difference: a scanner will see that the endpoint /api/orders/{id} returns 200 OK and stop there. A pentester will try substituting someone else's id, check whether the backend verifies the resource owner, and if it does not, this is no longer a "potential problem" but a working Broken Access Control with concrete proof.
Both approaches are needed, and they are not interchangeable. Vulnerability scanning is hygiene that you should do regularly and automatically. A pentest is a stress test of logic that shows what happens when a motivated human works against your application.
Methodology: What Pentesters Rely On
A good pentest is not a chaotic run through random ideas. It is a structured process built on recognized industry standards.
OWASP Top 10
The OWASP Top 10 is a list of the ten most critical risk categories for web applications, regularly updated by OWASP (Open Web Application Security Project) based on real incident data. It is not a checklist of "test these 10 bugs" but rather a map of risk categories: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Software and Data Integrity Failures, Security Logging Failures, and Server-Side Request Forgery. Each category covers dozens of specific techniques.
The OWASP Top 10 is a good entry point for understanding priorities, but it is not enough for a real pentest.
OWASP WSTG
The OWASP Web Security Testing Guide (WSTG) is a detailed testing methodology: specific test cases grouped into sections such as Information Gathering, Configuration Management, Identity Management, Authentication Testing, Authorization Testing, Session Management, Input Validation, Error Handling, Cryptography, Business Logic, and Client-Side Testing. Each section describes what exactly to check and by which methods.
The WSTG is what forms the "skeleton" of a real pentest. When you see a report where the items are grouped into sections like "WSTG-ATHN" (authentication testing) or "WSTG-ATHZ" (authorization testing), that is a sign the work was done systematically, and not on a "let's try a few known payloads and see" basis.
Black Box, Gray Box, White Box
The access model a pentester starts from significantly affects the result:
- Black box. The pentester has no internal information and tests the application as an anonymous external attacker. This is as realistic as it gets, but it costs more in time and may not cover all the logic.
- Gray box. The pentester gets limited access: test accounts for different roles, and sometimes basic API documentation. This is the most common and most balanced format. It simulates a real attacker (for example, a compromised user) while allowing far more of the logic to be covered in a reasonable time.
- White box. Full access, including source code. It is used less often for a classic pentest and is more frequently combined with code review, when maximum depth is required.
For most commercial web applications the optimal choice is gray box. It gives a realistic picture of what an authorized but dishonest user could do, and that is exactly the threat model that most often materializes in real incidents.
Key Web Application Vulnerabilities
Now to the heart of it, what exactly is happening during a web application pentest.
SQL Injection
SQL injection is when an attacker types a malicious command into an ordinary field on a site (a login form, for example), and the database treats it as its own instruction, handing over other people's passwords or data. SQL injections long ago stopped being what memes show with ' OR 1=1--. Modern applications rarely build queries by gluing strings together in a login form, but injections have not gone anywhere. They have simply moved. Today they hide in sorting parameters (?sort=name), in search filters passed into an ORM through "raw" query fragments, in JSON fields that the backend later drops into dynamic SQL, and even in HTTP headers that end up in logging queries to the database.
A good pentester does not just run sqlmap against every parameter. First they understand how the application builds its queries: whether parameterized queries (prepared statements) are used everywhere, whether there are places where the ORM "breaks out" into raw SQL for the sake of optimization, and whether there is second-order SQLi, where malicious data is first stored and then executed much later in a different context.
XSS (Cross-Site Scripting)
XSS is when an attacker leaves a hidden trap on a site, for example in a comment, and when a person opens that page, the trap fires in their browser and can steal access to their account. XSS is a classic that has also evolved. Reflected and Stored XSS are tested in the standard way, but the more interesting one is DOM-based XSS, which arises not on the backend but in client-side JavaScript, when data from the URL or postMessage lands in innerHTML without sanitization. In modern SPAs built on React/Vue/Angular, classic stored XSS happens less often thanks to the frameworks' auto-escaping, but new vectors appear instead: through dangerouslySetInnerHTML, custom Markdown renderers, or third-party libraries added without proper review.
SSRF (Server-Side Request Forgery)
SSRF is when an attacker tricks the site's own server into going to fetch data from somewhere outsiders are locked out of, for example the company's internal network, and hand that restricted data back. This is a vulnerability that deservedly made it into the latest OWASP Top 10 as its own item. If an application accepts a URL from a user and makes a request to that URL itself (for example, link preview generation, downloading an image by link, webhook integrations), an attacker can substitute an internal address and force the server to reach 169.254.169.254 (the metadata endpoint used by cloud providers) or internal services unreachable from outside. In cloud infrastructure this is one of the fastest paths from a "harmless" parameter to full compromise of an AWS or GCP account.
XXE (XML External Entity)
XXE is when an attacker sends the site a specially crafted file, and through it the site opens and hands over internal files from its own server, such as passwords or configuration. This is a less common vulnerability than it used to be, thanks to JSON displacing XML from most APIs, but XXE still lives wherever applications parse XML, SOAP, SVG files, or Office documents (which are XML under the hood). If the XML parser is not configured to forbid external entities, an attacker can read the server's local files through <!ENTITY> or trigger that same SSRF.
IDOR and Broken Access Control
This is the category we opened the article with, and not by accident. Broken Access Control has held first place in the OWASP Top 10 for several years running. The reason is simple: companies have learned to do authentication fairly well in recent years, with MFA, OAuth, and reliable libraries. Authorization is far harder, because every application has a unique access-rights model that nothing checks "out of the box."
A user can be correctly authenticated and at the same time gain access to someone else's order, invoice, or document simply by swapping an identifier or a role in the request. A pentester systematically goes through every endpoint with accounts of different roles and checks whether the backend really verifies the resource owner, or relies only on the frontend not showing the "other person's" button.
Authentication Issues
Here you check far more than just "can the password be guessed." This is resistance to brute force (whether rate limiting exists or not), the password-reset logic (whether the reset token can be substituted, whether it leaks through the Referer header), the JWT implementation (whether the signature algorithm is verified, whether alg: none can be substituted), session behavior after a password change or logout, and also the "remember me" logic and multi-factor authentication, namely whether it can be bypassed by re-sending the request without 2FA (two-factor authentication).
Business Logic Vulnerabilities
This is the hardest and most interesting category, because by definition it cannot be automated by a scanner. There is no signature for it. Examples: applying a promo code multiple times through parallel requests (a race condition), changing a product's price on the client before sending it to the cart, bypassing an attempt limit by changing a parameter the developer assumed no one would touch. Such vulnerabilities are found only through a deep understanding of how the application is supposed to work, and a systematic search for where that "supposed to" is not backed by a real check on the backend.
API Security and GraphQL
A modern web application is first and foremost a set of APIs, and REST/GraphQL APIs are tested as a separate block. For REST you check for mass assignment (when you can pass an extra field in the JSON and the backend accepts it, for example role: admin), missing permission checks at the level of individual HTTP methods, and excessive data exposure in responses.
GraphQL has its own set of risks: introspection left enabled in production (in which case an attacker sees the entire API schema laid out in front of them), the absence of limits on query depth and complexity (which allows a DoS with a single heavy nested query), and those same authorization problems, only now at the level of individual resolvers rather than endpoints, and each one has to be checked.
How a Web Application Pentest Works (Step-by-Step)
A pentest is not a single action but a sequence of phases, each with its own purpose.
- Scoping. You define exactly what gets tested: domains, subdomains, APIs, the application's mobile clients, or the infrastructure as a whole. Testing windows, escalation contacts for critical findings, and constraints (for example, do not touch the production payment gateway without warning) are all agreed in advance. This is the most important stage from the standpoint of legal and operational safety, because this is where the rules of engagement are signed.
- Reconnaissance. Gathering information about the target: subdomains, technology stack, public repositories, mentions on the web, outdated library versions. An OSINT component often plugs in here too, checking whether the company's secrets have been leaked even before active testing begins.
- Mapping / Enumeration. Building a full map of the application: all endpoints, parameters, user roles, and authentication points. Without good mapping it is impossible to cover the application systematically, and this is exactly where a shallow test differs from a deep one.
- Exploitation. The active phase: attempts to exploit the vulnerabilities found in the earlier stages and, where possible, chain them together. One medium-severity vulnerability (for example, a leak of an internal ID) combined with another (weak authorization checking) can produce a critical chain, and demonstrating such a chain is what separates a pentest report that influences prioritization from a plain list of findings.
- Validation. Every finding is checked for false positives and for real impact. Severity is assessed here too, usually using CVSS, with an adjustment for business context (for example, a vulnerability with a nominally medium CVSS that leads to a leak of customers' personal data may be raised in severity precisely because of the compliance context).
- Reporting. The final report is put together (more on that below).
- Remediation & Retest. The development team closes the problems found, after which a retest is carried out. The retest is what confirms the vulnerability has truly been closed rather than merely masked.
What’s Inside a Professional Pentest Report
A good pentest report is not just a PDF with a list of CVEs.
Structurally it usually contains:
- Executive Summary. A short summary for a CTO/CISO without deep technical jargon: the overall risk level, key findings, business impact.
- Methodology and scope. What exactly was tested and how, with a reference to OWASP WSTG/Top 10.
- Detailed findings. For each vulnerability: a description, reproduction steps (proof of concept), screenshots or requests/responses, a severity rating (CVSS), and business impact.
- Remediation recommendations. Concrete ones, not generic advice like "use parameterized queries," tied to a specific place in the code or configuration.
- A risk matrix. A summary table of all findings by severity, handy for planning sprints.
- Retest results. Confirmation of which problems are closed and which need further attention.
A report like this adapts easily to auditors' requirements, from ISO 27001 to PCI DSS or the NBU's requirements for fintech companies, precisely because the structure already matches the expected format of an evidence base.
Estimating Pentest Duration: How Long Does It Take?
The duration depends on the size of the application, the number of roles, and the depth of the business logic, but roughly:
- a small application (a page with a form, a simple MVP): 3 to 5 working days;
- a medium SaaS product with several roles and an API: 1 to 2 weeks;
- a complex platform with microservices and several clients (web plus mobile plus a partner API): from 3 weeks.
You should budget separately for the retest after the vulnerabilities are fixed, usually 20 to 30 percent of the initial scope of work.
Checklist: Are You Ready for a Pentest?
Before ordering a test, it is worth checking a few things. This speeds up the process and improves the quality of the result:
- There is a test or staging environment, as close to production as possible, with realistic data volumes (not an empty database).
- Test accounts are prepared for each role: a regular user, an administrator, guest access, a partner API key.
- There is up-to-date API documentation (Swagger/OpenAPI, GraphQL schema). This is not mandatory, but it significantly speeds up the mapping phase.
- The critical business processes that definitely need separate checking are identified (payment, changing email/password, account deletion).
- A contact person is assigned for the case of a critical finding that needs to be closed immediately, without waiting for the final report.
- A testing window is agreed with the monitoring team, so that SOC analysts do not confuse it with real incidents.
Companies that go through this checklist in advance usually get a deeper test for the same budget, simply because less time goes into blind reconnaissance and more into the real search for vulnerabilities.
The Future of Pentesting: Moving from Annual Events to Continuous AI Security
Here is where the classic pentest model runs into a structural problem. A web application changes every day: new features, new endpoints, updated dependencies, business logic altered after every release. A traditional pentest, meanwhile, is a one-time event done once a year, sometimes once a quarter if the budget allows.
This means that between two pentests the application spends a significant portion of its life in a state nobody has checked. A release that shipped the day after the test finished picks up a new Broken Access Control vulnerability, and no one finds out about it until the next cycle, which is to say possibly a year later.
This is exactly the gap between the speed of development and the speed of checking that AI agents close. At A42.tech this is implemented through the multi-agent AI Pentest system, where separate specialized agents cover the different phases of a classic pentest, recon, mapping, exploitation, and validation, but do it not once a year but continuously, syncing with every new release.
For example, the same OSINT agent we wrote about earlier constantly checks whether a secret has leaked into a public repository, a task that is practically impossible to cover with a one-off manual test, because a leak can happen on any day between audits. The agent responsible for exploitation validates findings not abstractly but by checking real exploitability, exactly as a human would, only without the several-week delay for scheduling.
This is not a replacement for a manual pentest where deep expertise in complex business logic or unusual architecture is needed. There, human experience is still irreplaceable. But for covering the OWASP Top 10, regularly checking new releases, and maintaining a continuous compliance status, AI agents provide what a one-off check cannot: consistency.
If your product ships releases more often than once a year, and today almost every team lives that way, it is worth thinking of a pentest not as an event but as a process.
Test your web application continuously, not once a year. Try our AI Pentest.
