Web application and API penetration testing
Manual testing of your web applications and APIs by consultants who think like attackers. We find the authentication, access control and business logic flaws that automated scanners miss, and show your developers how to fix them.
Why scanners are not enough
Your web applications are the part of your organisation that anyone on the internet can talk to. They hold customer data, take payments and connect to the systems behind them, and they change with every release. A scanner can tell you about a missing header or an outdated library. It cannot tell you that one customer can read another custome’s invoices by changing a number in a request.
That class of flaw, broken access control, sits at the top of the OWASP Top 10 for a reason. Finding it takes someone who understands what the application is supposed to do, then tries to make it do something else.
What we test
Authentication
Login, registration, password reset, MFA and single sign-on, plus how sessions, tokens and cookies are issued and expired.
Access control
Whether one user can reach anothe’s data or an admin function: horizontal and vertical privilege escalation, insecure direct object references and tenant separation.
Business logic
Workflows that can be skipped, repeated or reordered: discounts, approvals, limits, refunds and payments.
Injection and input handling
SQL and NoSQL injection, cross-site scripting, template injection, server-side request forgery and file upload abuse.
APIs
REST and GraphQL endpoints tested directly, including those the interface never calls, against the OWASP API Security Top 10.
Configuration and components
TLS, security headers, CORS, exposed admin panels, debug features and known-vulnerable libraries.
How the engagement runs
Scope
We agree the applications, environments and user roles, and anything off limits. A staging copy with production-like data is often the safest place to test.
Map
We walk the application as each role, record every endpoint and parameter, and load your API definitions if you have them.
Test
Manual testing guided by the OWASP Web Security Testing Guide, supported by tooling. Serious findings go into the portal as soon as we confirm them.
Report and retest
The report follows within five working days, with reproduction steps and fixes your developers can use. We then retest to close each finding.
What you get
- Each finding proved. Severity, the request and response that demonstrates it, the business impact and a specific fix.
- A summary for non-specialists. What was tested, what was found and what to do first, in plain language.
- Retest results. Evidence that each issue is closed, for your customers and auditors.
When to commission it
- Before a new application or major feature goes live.
- After changes to authentication, payments or permissions.
- When a customer, insurer or auditor asks for evidence of testing.
- At least yearly for applications holding personal or payment data, and more often for those that change every week.
Questions we get asked
What is the difference between API testing and web application testing?
Do you test the logged-in parts of the application?
Can you test our live environment?
Which standards do you follow?
Related
Infrastructure and networks
External and internal network penetration testing, including Active Directory. See how far an attacker could get from the internet or inside your network.
Read more →Mobile applications
Penetration testing of iOS and Android apps and the APIs behind them, aligned to OWASP MASVS: data storage, traffic, authentication and code.
Read more →Cloud: AWS, Azure, Google Cloud
Cloud security assessments and penetration testing for AWS, Azure, Google Cloud and Microsoft 365: identity, storage, network and real attack paths.
Read more →SavountHow to Secure Your DevOps Pipeline: Risks, Tools, and Best Practices
The risks in modern CI/CD pipelines, the tools that help, and the practices that keep secrets, dependencies and build systems away from attackers.
Read the article →