Web Application Penetration Testing

Works as designed. That’s the bug.

Your form shows two fields. A senior U.S. engineer sends a third the server never should have trusted, and a standard user saves themselves as admin. When we reach what matters, we leave a card.

  1. The browser sends

    POST /api/account/me
    {
      "name": "Ada Lovelace",
      "email": "ada@acme.io"
    }

    Two fields. All the form has.

  2. The attacker edits it

    POST /api/account/me
    {
      "name": "Ada Lovelace",
      "email": "ada@acme.io",  "role": "admin"
    }

    One line added, in transit.

  3. The server trusts it

    200 OK role updated

    • Valid 200
    • Mass assignment. Critical.
  • "role": "admin" The field the form never sent
  • Valid 200 What a scanner sees

Nothing replaces skill. Illustrative request. Valid schema, valid token, a field it should have refused.

Every Role, Every Workflow

Test from every angle your users and your attackers will. Most engagements are grey box: you give us test accounts at each role, and we work from there. Black box and white box when the goal calls for it.

Unauthenticated

Login, registration, and recovery flows. Injection, bypass, session fixation, and the endpoints nobody locked.

Standard User

Limited permissions, pushed upward. Vertical escalation, IDOR, and the authorization check that was never written.

Administrator

Full access, end to end. The misconfigurations and logic gaps an admin can break the system with, on purpose or by accident.

Cross-Tenant

One customer’s session, token, or input reaching another customer’s data, through any path. Quiet failures, loud when public.

OWASP Top 10:2025, All of It

Every engagement covers the full OWASP Top 10:2025. Coverage is the floor. Past it: CSRF, still common years after it left the list; business logic a scanner cannot reason about; and the API surface your front end depends on.

Broken Access Control

A01:2025

Horizontal and vertical escalation, IDOR, forced browsing, JWT manipulation, and SSRF against your internal services.

Security Misconfiguration

A02:2025

Default credentials, exposed admin panels, verbose errors, missing headers, open storage.

Software Supply Chain Failures

A03:2025

Compromised dependencies, dependency confusion, tampered pipelines, tested in your application’s actual context.

Cryptographic Failures

A04:2025

Plaintext where there should be none, weak TLS, predictable tokens, broken key handling.

Injection

A05:2025

SQL, NoSQL, command, LDAP, and XSS. How much your application trusts what it is given.

Insecure Design

A06:2025

Missing rate limits, abusable workflows, and trust boundaries that should not exist. The application you meant to build, tested against the one that shipped.

Authentication Failures

A07:2025

Credential stuffing exposure, weak MFA enrollment, predictable sessions, and reset flows that leak.

Software or Data Integrity Failures

A08:2025

Insecure deserialization, unsigned updates, third-party scripts with no integrity check.

Security Logging and Alerting Failures

A09:2025

The events you do not log, and the alerts that never fire while we are inside.

Mishandling of Exceptional Conditions

A10:2025

Access control that holds on the happy path and fails open on the error path.

How We Test

Guided by the OWASP Web Security Testing Guide and grounded in MITRE ATT&CK. The pentester on your scope call is the one attacking the application, and the one retesting your fix.

01

Scope and Access

Black, grey, or white box. Roles, environments, rules of engagement, and anything that needs care.

02

Map by Tool, Attack by Hand

Automation does reconnaissance and known-CVE checks. Engineers do exploitation, logic abuse, and chaining. That is most of the value.

03

Findings As We Go

Criticals and highs land in Raxis One with proof and a fix as we find them. The engineer testing your app is the one you talk to.

04

Retest and Verify

You fix. We confirm, at no extra cost, and issue the clean report.

Two Ways to Test Your App

Same senior engineers, same manual tradecraft, same live findings. The difference is when you want us on it: once, before a launch or an audit, or every release.

What You Get

The report is our calling card. Written by the engineer who did the work, for the team that has to fix it.

Technical Report

Every finding with proof, reproduction steps, impact, and a fix, from the engineer who found it.

Executive Summary

A board-readable read on the risk and the actions that move it.

Live Debrief

Walk the findings with the engineer who did the work.

Included Retest

We verify the fix and issue a clean report, at no extra cost.

One Quote

Our stories are based on real events encountered by Raxis engineers. Some details have been altered or omitted to protect customer identities.

Running the usual unauthenticated checks against a small e-commerce site, our pentester found that the login form took a single quote and kept going. A classic ’ OR 1=1 opened customer accounts, then administrator accounts.

He fed the vulnerable request to SQLMap. It enumerated the databases, then the tables, then pulled the whole thing: encrypted passwords and personal information for every user, admins and customers alike.

It was a critical, so the customer heard about it that day, with the fix. They patched it inside the testing window and our pentester confirmed the remediation before the engagement closed. He did log in as the CEO first, for the screenshot in the report.

FAQ: Web Application Penetration Testing

What is web application penetration testing?

Web application penetration testing is a manual security assessment in which engineers attempt to exploit vulnerabilities in your web application the way an attacker would. It goes beyond automated scanning to find business logic flaws, broken access control, authentication weaknesses, and chained exploits that scanners can't reason about.

How is this different from a vulnerability scan?

A vulnerability scan compares your application against a database of known issues. A penetration test exploits those issues, chains them together, and finds the ones that aren't in any database. Scanners are useful inputs to a pentest. They are not a substitute for one.

What kinds of web applications can Raxis test?

Customer-facing portals, internal applications, SaaS platforms, single-page and server-rendered apps, multi-tenant systems, complex role hierarchies, applications behind SSO, and applications that depend on third-party APIs. We have tested in nearly every framework on the market.

Black box, grey box, or white box. Which should I choose?

Grey box is the most common and usually the most useful. You provide test accounts at each role level, and we work from there. Black box is closer to a real external attack but slower. White box, with source code review, goes deepest and is most valuable for high-stakes or pre-launch applications.

Will testing affect production users?

We work with you to scope around production safety. Most engagements run against staging or pre-production environments that mirror production. When production testing is required, we coordinate timing, throttle our activity, and avoid destructive techniques unless explicitly authorized.

What deliverables do I receive?

A detailed technical report with proof-of-concept evidence and remediation guidance, an executive summary suitable for board and audit use, real-time findings in the Raxis One portal during the engagement, and a remediation retest at no extra charge once your team has implemented fixes.

How often should we test our web applications?

At minimum, annually and after any major release, framework upgrade, or change to authentication or authorization. For applications under continuous development, a once-a-year cadence leaves long windows of unvalidated change. Continuous testing through Raxis Attack closes that gap.

Can Raxis test SaaS applications with multiple customer tenants?

Yes. Multi-tenant testing is one of our specialties. We validate that customer A cannot see, modify, or impact customer B's data through any path, including direct object references, shared resources, indirect channels, and abuse of administrative interfaces.

Does this include API penetration testing?

Web application engagements cover the APIs your application directly depends on. For dedicated, comprehensive API testing across REST, GraphQL, SOAP, and gRPC interfaces, including ones not exposed through a web UI, see our API Penetration Testing service.

How long does a web application penetration test take?

Most engagements run one to two weeks of active testing depending on the size of the application, the number of roles, and the complexity of its workflows. Critical findings reach you in real time through Raxis One, and the full report follows within days of testing completion.

How much does a web application penetration test cost?

Cost scales with the size and complexity of the application: the number of roles, workflows, and endpoints in scope is the biggest driver. Be wary of quotes that seem too low; they usually mean an automated scan with a pentest label. Contact us for a quote scoped to your application.

Who performs the testing?

Senior US-based Raxis engineers holding certifications such as OSCP and OSWE. Your test is never outsourced, and the engineer who exploits your application is the same person who writes your report and walks you through it.

Can you test applications behind SSO or MFA?

Yes. We regularly test applications behind SAML, OAuth, and OIDC single sign-on as well as multi-factor authentication. We coordinate test accounts and access during scoping, and the SSO and MFA flows themselves are part of what we attack.

Do you test AI features like chatbots and LLM integrations?

AI features in scope are tested as part of the application, including prompt injection and data exposure through LLM integrations. For deep testing of AI systems themselves, see our AI and LLM Penetration Testing service.

Request a quote

Tell Us What You Need Tested

We usually respond in one business day.

Please let us know what's on your mind. Include any details about your target environment, timeline, or compliance drivers.