Web & API penetration testing
Find out what’s actually exploitable in your web app and APIs.
Your application and its APIs are tested by hand, role by role and workflow by workflow. Can someone read another customer’s data, skip a payment step, take over an account?
Discuss my scopeWhat’s tested
Anonymous visitor and logged-in customer · both included
| Starting point | Your app and APIs, first as an anonymous visitor, then logged in as each user role |
|---|---|
| You provide | URLs, API docs if you have them, and two test accounts per role |
| We test |
|
| The goal | What someone could actually do: get in, reach other customers’ data, or bend the rules |
| Based on | OWASP WSTG · OWASP API Security Top 10 |
| You get |
|
What a finding looks like
Only verified findings, each with its impact, proof and a concrete fix, ordered by what to fix first.
Any logged-in user can read other customers’ invoices
GET https://api.example.com/v1/invoices/{id}
- Impact
- Names, addresses and amounts of every customer can be downloaded by any account, including a free trial.
- Proof
- Logged in as user A, requested invoice 10482 that belongs to user B: the API returned it in full.
- Fix
- Check on the server that the invoice belongs to the caller’s account before returning it, in every endpoint that takes an invoice ID.
FAQ
-
What comes with every engagement?
Every engagement is led by a senior tester and done by hand. During testing, a shared chat channel and a weekly call keep you up to date, and anything critical is reported straight away. After the report you get a readout call and one retest.
-
When is the right time for a test?
Before a launch, or after big changes to login, user roles or payments. Also when a larger customer asks for a recent penetration test report, or ahead of due diligence for a funding round or an acquisition.
-
Production or staging? Will our users notice?
You choose. Staging is safer for anything that changes data; production shows the real configuration. Either way there is no load testing, and anything risky is agreed with you before it is tried, at a time that suits you.
-
How is this different from a vulnerability scan?
A scanner finds known patterns, such as outdated software or a missing header. It can’t tell that one customer can open another customer’s invoice, or that a discount can be applied twice. Those flaws are found by a person who understands what the application is supposed to do.
-
Will the report help with SOC 2, ISO 27001 or a customer questionnaire?
Yes. SOC 2 and ISO 27001 auditors usually expect a recent penetration test, customer security questionnaires often ask for one, and PCI DSS requires it. The report states the scope, the method, every finding and the retest results, which is what auditors and customers’ security teams ask to see.
-
What isn’t part of this test?
Denial-of-service and load testing, phishing and social engineering, physical security and full red-team exercises. The servers and cloud underneath the application are a separate assessment.
-
Do you sign an NDA?
Yes, before any details are shared.
-
What language is the report in?
The report is in English.
Get in touch
Tell us which application and APIs you would like tested.
What happens next
-
We reply within 24 hours
By email, with a link to book a call with the team.
-
Intro call
We learn what you need and answer your questions.
-
Proposal
Scope, timing and price, in writing. Nothing starts before an NDA is signed.
Prefer email? Write to hello@alteasecurity.com