Web penetration testing: web application security assessment

Your web application is the gateway to your data, your customers and your business. We assess its security the way a real attacker would, covering everything from the OWASP Top 10 to the specific vulnerabilities of your technology stack.

Scope your project · Request a web assessment

Rather talk it through? Call us at +34 960 730 013

OWASP Top 10:2025 — Full coverage of the current edition, plus your business logic
Gray box — Two accounts per role to test authorization between users
Same day — Immediate notice if something critical comes up, without waiting for the report
Retest — Verification of the fixes included

Web applications are the most exploited attack vector

Your web application is the part of your company exposed to the internet 24/7 and reachable by anyone. Broken Access Control has topped the OWASP Top 10 since the 2021 edition and remains the A01 risk in the 2025 edition. SQL injection, XSS, sensitive data exposure, weak authentication, inadequate access control... Most of these flaws are silent: your app works perfectly while a back door stays open. Web pentesting finds them and closes them before someone else does.

How three "medium" flaws end in an administrator account takeover

A scanner would score them one by one and none would look urgent. Chained together, they hand over the application. This is the kind of path a manual web pentest reproduces.

User enumeration (A07): The password recovery form responds differently when the email exists: the administrator's account is confirmed. No alert: looks like normal traffic
Weak recovery token (A07): The code has 6 digits with no attempt limit and no short expiry: it can be guessed in minutes. Thousands of attempts, no lockout
Admin panel with no role check (A01): Once inside, admin actions are only hidden in the interface; the API accepts them from any session. Logged, nobody reviews it
Bulk export (A01): The customer export feature downloads the entire database as CSV. No volume alert

Impact: Every customer's data and full control of the application, starting from nothing but the administrator's email address.

Illustrative chain built from findings that are common in web assessments; it does not describe a specific client.

What we cover in a web pentest

Full OWASP Top 10:2025: access control, configuration, supply chain, cryptography, injection (SQL, XSS, templates), design, authentication, integrity, logging and error handling
SSRF, file uploads, insecure deserialization and open redirects
Business logic: bypassing purchase flows, privilege escalation, data manipulation
Authentication and session management: tokens, cookies, 2FA, password resets
Access control: BOLA/IDOR, horizontal and vertical access to resources
Server configuration: HTTP headers, TLS, CORS, CSP
Exposure of sensitive information in responses, errors and metadata

Web pentesting methodology

Reconnaissance and mapping: We identify the attack surface: subdomains, technologies, exposed endpoints, framework versions.
Authentication analysis: We assess the login flow, session management, password policies and 2FA mechanisms.
Manual logic testing: We review critical business flows: purchases, user roles, permissions, state changes.
Vulnerability exploitation: We confirm and exploit each finding in a controlled way to measure its real impact.
Documentation and delivery: Each vulnerability includes a description, evidence (screenshots, requests/responses), CVSS and steps to reproduce it.

The ten risks we test your application against

The reference list for web security, in its 2025 edition. Tap a risk to see what it is and how we test for it; the colours group the ones that share a cause.

A01:2025 Broken Access Control (Access control): A user reaches data or actions they shouldn't: another company's invoices, admin functions, other people's objects by their identifier. Includes SSRF as of this edition. We test every role against the others' resources with two accounts per role, in the interface and directly against the API.
A02:2025 Security Misconfiguration (Configuration and cryptography): Default settings, exposed panels, permissive CORS, missing security headers or detailed errors in production. We review the server, framework, headers, CORS, CSP and the environments and paths that shouldn't be published.
A03:2025 Software Supply Chain Failures (Supply chain and integrity): Dependencies, JavaScript libraries, images or third-party services with known vulnerabilities or that have been compromised. We identify exposed components and versions and check whether their known vulnerabilities are exploitable in your application.
A04:2025 Cryptographic Failures (Configuration and cryptography): Unencrypted sensitive data, weak TLS, passwords hashed with obsolete algorithms or predictable secrets. We analyse TLS, cookies, tokens, credential storage and which data travels or is stored in clear text.
A05:2025 Injection (Injection and design): SQL, NoSQL, OS commands, templates or XSS: the application interprets as code what should be data. We test every input manually and with tools, and confirm the real impact of what we find.
A06:2025 Insecure Design (Injection and design): Business logic flaws a patch won't fix: stackable discounts, payment steps that can be skipped, limits that don't exist. We review your critical business flows —purchases, sign-ups, approvals— looking for ways to abuse them.
A07:2025 Authentication Failures (Identity and session): Login with no brute-force protection, weak password recovery, sessions that never expire or 2FA that can be bypassed. We attack login, recovery, 2FA and session and token handling end to end.
A08:2025 Software or Data Integrity Failures (Supply chain and integrity): The application trusts data or code it doesn't verify: insecure deserialization, unsigned updates, third-party scripts with no integrity check. We look for serialized objects, poorly validated signed data and external resources loaded without control.
A09:2025 Security Logging and Alerting Failures (Configuration and cryptography): Attacks that leave no trace or trigger no alert, which lets any intrusion run longer. We check with your team what was logged and which alerts fired during our testing.
A10:2025 Mishandling of Exceptional Conditions (Injection and design): Poorly handled errors that leave the application in an insecure state: failures that fail open, exceptions that leak information. We force unexpected inputs, timeouts and partial failures to see how the application reacts.

Phases of a web pentest, step by step

Deliverables

Executive report: overall exposure, business risk, action priorities
Technical report: each vulnerability with PoC, CVSS and recommended fix
Every finding classified by OWASP Top 10:2025 and CVSS
Review meeting with the development team
Retest of the fixes included, with an updated report

What types of applications do we test?

E-commerce with payment gateways and card data (PCI-DSS)
B2B SaaS with multi-user access and sensitive customer data
Corporate portals, intranets and extranets
Business applications (ERP, CRM, HCM) exposed to the internet
WordPress, Magento, PrestaShop and other CMSs with third-party plugins
Public or semi-public web APIs

Web pentest, scanner or bug bounty: what each one gives you

They aren't mutually exclusive, but they don't do the same job. What each approach finds and when it makes sense.

	Automated scanner	Bug bounty program	Manual web pentest
What it finds	Cataloged flaws: versions, headers, known patterns	Whatever participating researchers find	Cataloged flaws, business logic and chains of flaws
Access control between users	Almost never	Depends on the accounts they have	Systematic, with two accounts per role
Coverage	Broad but shallow	Uneven: focused on what pays most	Complete over the agreed scope
Deliverable	A list of unvalidated alerts	Individual reports, each in its own format	Executive and technical report with PoC and retest
When it fits	Continuous monitoring between pentests	A mature product after several pentests	Before launch, after major changes or when a client requires it

Compare with

Frequently asked questions

Do you do black-box, gray-box or white-box testing?

All three. Black box simulates an external attacker with no prior information. Gray box includes standard user credentials to assess access control. White box includes access to the code and architecture and allows a more exhaustive analysis. Most clients choose gray box as a balance between realism and coverage.

Do you assess WordPress and other CMSs?

Yes. WordPress is the most attacked CMS in the world precisely because of the proliferation of vulnerable plugins. We assess the core, the installed plugins, the themes, the server configuration and how access to the admin panel is handled.

Can you sign an NDA before starting?

Always. Before you share any data about your infrastructure, we sign a confidentiality agreement.

What happens if you find critical vulnerabilities?

We notify you immediately (same day) if we find something that poses a serious and immediate risk to your business, without waiting for the full test to finish.

Can the pentest run against production, or do you need a staging environment?

It can run against production and usually does, because a staging environment with fake data and a different configuration hides exactly what is worth finding. What gets agreed beforehand is the intensity profile, an execution window for tests that may generate load, and a direct contact line to stop mid-run if anything degrades. Potentially destructive tests are discussed with you before they are run, never after.

What do you need to start: credentials, source code, documentation?

It depends on the testing model agreed (black, gray or white box). Black box needs only the URL and written authorization. Gray box — the most cost-effective option for an application with users — needs two accounts per distinct role, because without them authorization between users cannot be tested, and that is where the highest-impact findings appear. Source code is only required if a static code review is also part of the engagement.

How is this different from running a vulnerability scanner?

A scanner finds what is already cataloged: outdated versions, missing headers, known patterns. It does not find broken business logic, which is specific to your application: a discount that can be applied twice, someone else's order whose status can be changed, a payment flow that can be completed while skipping a step. That requires understanding what the company actually does, which is why no tool automates it.

How long does a web pentest take?

The technical phase usually takes 3 to 10 business days, depending on the number of roles, flows and features, and the report arrives 2-3 days later. The exact timeline is set in the proposal, with fixed scope and price.

How often should it be repeated?

At least once a year and always after a significant change: a new feature that handles sensitive data, a change of authentication or provider, or a migration. Between pentests, recurring vulnerability assessment keeps watch over cataloged flaws.

Before you hire

Understand the difference

If your site is more than a website

Sources

Ready to protect your business?

Answer the scoping form at your own pace and we'll use it to prepare your proposal. If you'd rather talk first, book a free 30-minute call.

Scope your project · Request a web assessment