Service 1.1
Web application penetration testing.
We test your web application the way an attacker would: first from outside with no account, then signed in with each role. Every finding comes with its proof and its fix.
1 What we test
- Access control: whether one user or role can see or change what belongs to another. It is the most common serious flaw in web applications, first in the OWASP Top 10:2025.
- Sign-in and sessions: login, password reset, multi-factor, session length and sign-out.
- Business logic: steps a user can skip, repeat or reorder, around prices, quotas, invitations and approvals.
- Input handling: every place the application takes data from a user, checked for injection into the database, the page or the server.
- File upload and download: whether a file can reach other users or the server.
- Configuration: security headers, error messages, files left online and third-party scripts.
Method: OWASP WSTG, 12 test families, NIST SP 800-115.
2 Not included
Denial of service, social engineering, third-party services you do not own.
3 What you provide
- The URLs in scope, and whether we test production or a staging copy.
- One test account for each role, and two for any role whose users must not see each other’s data.
- API documentation, if the front end calls an API. It is optional, and it widens what we cover in the same time.
- A contact we can call during the test windows.
- If a firewall or rate limit could block us, an allow list for our fixed IP addresses. We send them before the test.
4 How the test runs
- Scope call: we agree the URLs, the roles, the test windows and who to call. You get a written offer with dates and price.
- You sign the authorization. Nothing reaches your application before that.
- Test with no account: what anyone on the internet can reach.
- Test with accounts: each role tries to reach what belongs to another.
- A critical finding goes to your contact as soon as it is proven. It does not wait for the report.
- Report and readout, then a retest once you have fixed.
5 What you get
| Document | What it holds | For |
|---|---|---|
| Technical report | Each finding with its exploit path, proof, CVSS 4.0 score, CWE and fix. | Developers, IT |
| Executive report | Five to eight pages on business risk, in plain words. | Management, board |
| Remediation plan | Findings ranked by what to fix first. | IT, project leads |
| Readout | A remote session to walk through the findings and answer questions. | Both |
| Retest attestation | Proof that the findings were fixed. | Auditors, clients |
6 Questions
- How long does it take?
- It depends on the number of roles and features. The written offer gives the number of testing days and the dates before you sign.
- Will it disrupt production?
- Tests stay inside agreed windows, come from fixed IP addresses, and never deny service or change your data. If you prefer, we test a staging copy that matches production.
- Do you need our source code?
- No. We test from the outside, as a user would. If you share code or documentation, we can go deeper in the same time.
- Can we share the report with a client or an auditor?
- Yes. The executive report and the retest attestation are written to be shared.
Get a scope for this test
Tell us what needs testing. A tester replies with a written offer: scope, dates and price.
Request a scope