API & Web Services Penetration Testing
Manual testing of REST, GraphQL, SOAP, and gRPC services: object-level and function-level authorization, authentication, mass assignment, and the trust assumptions between services.
Service 02
Web application penetration testing
Your application is the part of your business the whole internet can reach. We test it the way a motivated attacker would: by learning how it is supposed to work, then finding every place it can be made to do something else.
Overview
The problem we are solving
Scanners are good at spotting a missing header or an outdated library. They are poor at noticing that one tenant can read another tenant's invoices by changing an ID, that a discount can be applied twice, or that a password reset flow trusts a value it should never trust. Those are the findings that matter, and they come from manual work.
Every engagement starts with understanding the application: its roles, its data, its workflows, and the assumptions its developers made. Testing then targets the places where those assumptions break, with automated tooling used for coverage and every candidate finding confirmed by hand before it reaches the report.
Testing follows the OWASP Web Security Testing Guide and maps findings to the OWASP Top 10 and ASVS, so results are defensible to customers, auditors, and your own engineering team.
Coverage
What we test
Scope is agreed up front; these are the areas an engagement typically covers.
- Authentication & session handling
- Login, registration, password reset, MFA enrollment and bypass, SSO and OAuth/OIDC flows, session fixation, token handling, and logout that does not actually log you out.
- Authorization & multi-tenancy
- Horizontal and vertical privilege escalation, insecure direct object references, role and permission boundaries, and cross-tenant data access in shared platforms.
- Business logic
- Workflow and state abuse, race conditions, price and quantity manipulation, skipped steps, and the features that work exactly as coded but not as intended.
- Injection & input handling
- SQL and NoSQL injection, cross-site scripting, server-side template injection, command injection, XXE, deserialization, and file upload handling.
- Server-side & integration flaws
- Server-side request forgery, insecure redirects, cache and request smuggling issues, and trust between the application and the services it calls.
- Backing APIs
- The REST or GraphQL endpoints the front end uses (and the ones it no longer uses): object-level and function-level authorization, mass assignment, and rate and resource abuse.
Methodology
How the engagement runs
-
01
Scoping & access
Target environments, user roles, test accounts, testing windows, and out-of-scope functionality are agreed and documented. Testing against staging or production is decided together.
-
02
Application mapping
Walking every role through the application, cataloguing endpoints, parameters, and workflows, and building a model of how data and permissions are supposed to flow.
-
03
Manual & automated testing
Automated coverage for breadth, then manual testing of authentication, authorization, business logic, and input handling against the model built during mapping.
-
04
Exploitation & impact
Confirmed findings are exploited far enough to prove real impact, and chained where possible: a low-severity leak that enables a high-severity takeover is reported as what it actually is.
-
05
Reporting
Ranked findings with evidence, reproduction steps, and remediation guidance written for the framework and language your developers actually use.
-
06
Debrief & validation handoff
A live walkthrough with the engineers who own the fixes, with validation steps for every finding so your team can confirm remediation on its own.
Deliverables
What you receive
- Full technical report with ranked findings, evidence, and reproduction steps
- Executive summary with overall risk posture and recommended priorities
- Findings mapped to the OWASP Top 10 and ASVS
- Remediation guidance specific to your framework and stack
- Validation steps for every finding, so your team can confirm and close out each fix on its own
- Live debrief with engineering and leadership
Aligned to
- OWASP Web Security Testing Guide
- OWASP Application Security Verification Standard
- OWASP Top 10
- OWASP API Security Top 10
- Penetration Testing Execution Standard (PTES)
Questions
Frequently asked
Should we test staging or production?
Staging is usually preferred when it closely mirrors production, since it lets testing go further without risk to real data. Some issues only exist in production configuration, so we will talk through the tradeoffs during scoping and agree on what makes sense.
Do you need source code?
No, but it helps. Grey box testing with test accounts for each role gives the best return for most clients. Source code access lets us confirm root causes faster, and it can be paired with an source code review for deeper coverage.
Does this cover our API?
The APIs your web application depends on are in scope by default. Standalone or partner-facing APIs can be included as well; mention them during scoping so they are sized properly.
Will this satisfy SOC 2 or a customer security review?
Yes. The report is structured to serve as evidence for SOC 2, ISO 27001, HIPAA, and customer security questionnaires, and each finding includes validation steps your team can document to show remediation happened.
Related
Often scoped together
Penetration Testing
Manual, objective-driven testing of web applications, APIs, and networks (internal, external, wireless, and physical), built on hands-on consulting experience since 2018, not a scanner with a report template.
Get started
Ready to scope web app testing?
Scoping conversations are free and usually take twenty minutes. You will speak directly with the consultant who would do the work.
Request an assessment
or reach out directly, (608) 520-0719 sales@infocus-security.com