Offensive & Application Security
Web application and API security testing
In-depth testing of web applications and APIs, focused on authentication, authorisation, business logic and data exposure.
Key areas covered
- Coverage
- Web applications, single-page apps, and REST, GraphQL and SOAP APIs
- Approach
- Authenticated, role-by-role testing (grey-box) recommended
- Reference standards
- OWASP WSTG, OWASP ASVS, OWASP Top 10, OWASP API Security Top 10 (2023)
- You receive
- Executive summary, technical report with reproducible requests, debrief and optional retest
Overview
About web application and API security testing
Web applications and APIs hold most organisations’ customer data and most of their business logic. Our testing goes beyond automated scanners to check what a determined user or attacker can actually do: bypass a login, view another customer’s records, change a price, or call an API that was never meant to be called directly.
This is penetration testing focused on the application layer. If your servers and network also need testing, we can combine this with infrastructure penetration testing in one engagement. For white-box coverage, it pairs well with secure code review.
A typical starting point
You are launching or changing a customer-facing web app, portal or API and need it tested before attackers do.
The security problem
The application risks we test for
Broken access control
Users can see or change other customers’ data by changing an ID in a request, one of the most common and serious API flaws.
Authentication and session weaknesses
Weak login, password reset or session handling lets attackers take over accounts.
Business logic abuse
Workflows such as discounts, approvals or payments can be manipulated in ways no scanner understands.
Injection and data exposure
Untrusted input reaching databases or interpreters, and APIs returning more data than the screen shows.
What’s covered
What we test in web applications and APIs
Area 01
Authentication and sessions
- Login, multi-factor authentication, password reset and account recovery
- Session handling, timeout and logout
- JWT handling, and OAuth 2.0 and OpenID Connect flows
Area 02
Authorisation and access control
- Horizontal and vertical privilege escalation
- Insecure direct object references (IDOR) and broken object level authorisation (BOLA)
- Tenant isolation in multi-tenant applications
- Protection of administrative functions
Area 03
Input handling and injection
- SQL and NoSQL injection, and command and template injection
- Cross-site scripting (XSS) and client-side injection
- Server-side request forgery (SSRF) and XML external entities
- File upload handling and path traversal
Area 04
Business logic
- Workflow bypasses and skipped steps
- Price, quantity, coupon and credit manipulation
- Race conditions and replayed requests
- Abuse of rate limits and automation of sensitive actions
Area 05
API-specific risks
- Broken object, property and function level authorisation
- Mass assignment and excessive data exposure
- Unrestricted resource consumption
- Undocumented and legacy endpoints; GraphQL introspection and query depth
Area 06
Configuration and data protection
- Security headers, CORS policy and TLS
- Error handling and information leakage
- Sensitive data in responses, URLs, logs and browser storage
Our approach
How a web application and API test is carried out
Step 1: Scoping and walkthrough
We agree the application, environments, user roles and critical workflows, ideally with a short walkthrough from someone who knows the product.
Step 2: Mapping
We map the application and API surface, including hidden, undocumented and legacy endpoints.
Step 3: Automated and manual testing
Scanner-assisted checks find common issues quickly. Most of the time goes on manual testing of each role and each critical workflow.
Step 4: Impact validation
We confirm each finding with a safe proof of concept that shows real impact without damaging your data.
Step 5: Reporting and debrief
Findings are documented with reproducible requests, then walked through with your developers.
Step 6: Retesting (optional)
Once fixes are deployed, we verify them and issue an updated report.
Standards and references we work to
- OWASP WSTG
- Web Security Testing Guide: the test cases behind our methodology.
- OWASP ASVS
- Application Security Verification Standard: a requirements checklist we can verify against.
- OWASP API Security Top 10 (2023)
- The most critical API risks, used to categorise API findings.
- OWASP Top 10
- The widely recognised list of critical web application risk categories.
- CVSS
- Consistent severity scoring for every finding.
What you receive
What you receive from a web or API test
Executive summary
Overall risk, the most significant issues and recommended priorities, in plain language.
Technical findings
Each issue with affected endpoints, CVSS severity, OWASP category, reproduction steps with HTTP requests and responses, impact and remediation guidance.
Coverage statement
The roles, features, environments and API endpoints tested, and anything that was out of scope or not reachable.
Debrief with developers
A working session to walk through findings, discuss fixes and answer questions.
Retest report
If retesting is in scope, confirmation of which findings are resolved.
Sample finding
Customers can access and modify other customers’ invoices
api.example.com/api/v1/invoices/{id}
OWASP API Security Top 10 (2023): API1 Broken Object Level Authorization
- What we found
- Any signed-in customer can view and change other customers’ invoices by changing the invoice number in the request.
- Evidence
- As test customer A, we retrieved and then edited invoice 10482, which belongs to test customer B. Requests, responses and screenshots attached.
- Business impact
- Every customer’s billing records can be exposed or altered, with likely notification duties under the DPDP Act.
- Fix
- Check invoice ownership on the server using the customer ID from the session, not the request. Add automated cross-account tests.
- Status
- OpenFixed, verified at retest
Good to know
Security testing is not QA testing
Quality assurance (QA) testing checks that your application does what it is supposed to do. Security testing checks what it can be made to do that it shouldn’t. The two need different skills, tools and mindsets.
Cenvox provides application security testing. We do not provide functional, regression or performance QA testing.
Good to know
A DAST scan is not a penetration test
Dynamic application security testing (DAST) tools are good at finding known patterns such as missing headers or reflected XSS. They cannot understand your business rules, so they rarely find authorisation flaws or logic abuse, which are among the most damaging issues in modern applications.
Before we start
What we need to test your application
- A stable test environment, ideally a staging environment that mirrors production, or agreed testing windows in production.
- Test accounts for each user role, ideally two per role so cross-account access can be tested.
- API documentation, such as an OpenAPI (Swagger) specification, Postman collection or sample requests.
- A decision on web application firewall and rate limiting: allow-list our testing IP addresses if you want the application tested rather than the firewall.
- A contact who can reset test data and accounts during testing.
Not sure you have everything?
We confirm exactly what web application and API testing needs from your side during the scoping call, before any work is agreed.
Book a scoping callFAQ
Questions about web application and API testing
Still have a question?
Ask about scope, timing or cost for web application and API testing, even if you are not ready to commission work yet.
Contact our teamShould we test in staging or in production?
Staging is usually better, as long as it closely mirrors production. Testing can then include actions that create, change or delete data without affecting real customers. If staging differs significantly from production, we can test production carefully within agreed windows and limits.
Do you need our source code?
No. Most application tests are grey-box: we use the application as your users would, with test accounts. Access to source code allows a deeper white-box assessment, which we offer as secure code review.
How do you test an API that has no user interface?
We work directly with the API using its documentation or a Postman collection, sending crafted requests to each endpoint with different roles and inputs. If no documentation exists, we can map the API from the traffic of the web or mobile app that uses it.
Will testing affect our real users or data?
Not if testing is carried out in staging. In production we use dedicated test accounts, avoid destructive actions unless agreed, and do not run denial-of-service tests. Any finding that exposes real customer data is reported to you immediately rather than waiting for the report.
Can you test an application that sits behind a WAF?
Yes. We can test with the web application firewall in place, which shows what an outside attacker would face, or with our addresses allow-listed so the application’s own security is tested. Many organisations choose the second option, because a WAF can be bypassed or misconfigured later.
How often should applications be tested?
At least annually, and after major releases or changes to authentication, payments or data access. Fast-moving products often test their highest-risk features each quarter.
Related services
Often combined with web application and API testing
Talk to us about web and API security
Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for web application and API testing.