Web application penetration testing.
Your web application is not a marketing site. It is where your business actually runs: transactions, customer data, permissions. We test it where automated scanners stop — business logic, access control, and the code that runs in the user's browser.
We secure the Czech tech companies that made it globally.
Web applications run the business
A website used to be the gateway to a company. Today, web applications run the business: online banking, customer portals, SaaS products, back-office systems in a browser, the API behind a mobile app. They handle the operations you can least afford to get wrong — payments, contracts, personal data, and who is allowed to do what.
So "can someone get in?" is the wrong question. The right one is: what can a logged-in user do once they decide not to follow the rules? That is the question our web application penetration testing is built around.
An API is not a separate product. It is the same application without a user interface, and we test it within the same scope (ASVS V13) — REST and GraphQL alike.
What a scanner cannot see
An automated scanner sends hostile input to the backend — SQL injection, XSS, path traversal — and waits for something to break. We do that too, by hand and with tooling, but it is the easy part. A scanner does not know your roles, does not know the intended order of a workflow, and never reads the code you ship to the browser. That is where the serious findings are.
Business logic and access control
An application follows rules no scanner knows: who may do what, in which order, at what price. We test what happens when someone who knows the rules breaks them. A negative quantity in the cart. A coupon redeemed twice in two concurrent requests (race condition). A verification step skipped by calling the next one directly. A price changed in the request that the frontend "does not allow". At the HTTP level everything looks valid, so a scanner never flags it.
Most applications have more than one role, and often more than one customer on the same instance. We build the permission matrix and break it systematically: horizontally (user A reads user B's data — IDOR, BOLA), vertically (an ordinary user calls an admin function — BFLA), and across tenants (client A sees client B's data). Whether the button is missing from the UI does not matter. What matters is whether the endpoint behind it refuses the request.
Client side: the code that runs in the user's browser
A modern application is largely JavaScript running in the browser. React, Angular, Vue — the whole bundle ships to the client, including functionality this particular user was never meant to see. We take apart what actually arrives in the browser: hidden admin routes, feature flags, API keys and secrets left in the code, source maps, and validation or authorization logic that exists only on the client. We test DOM XSS, postMessage handling, prototype pollution, CSP and CORS configuration, and how tokens are handled in localStorage and cookies (HttpOnly, Secure, SameSite). Everything that runs on the client is under the attacker's control. A test that stops at the backend covers half the application.
How the test works
Every web application penetration test has three steps — so you know exactly what you are getting.
Attack surface mapping
Runtime, framework, dependencies, API endpoints — including forgotten older versions — leaked Swagger/OpenAPI specs, and the contents of the JS bundle. An application's attack surface is usually wider than its navigation suggests.
Manual testing and exploitation
Authentication and sessions: session management, JWT, OAuth/OIDC and SSO, MFA, password reset, rate limiting. Authorization across roles and tenants. Business logic. Input handling and the backend: SQLi, NoSQL injection, command injection, SSTI, XXE, SSRF, deserialization, file upload, request smuggling. Client-side code. Every finding is confirmed by actual exploitation — you will not find "potential vulnerability" in our report.
Chaining and real impact
We combine individual findings into an attack and show how far an attacker gets. Severity is rated by CVSSv3 on actual impact, not on a tool's score.
Methodology: OWASP OTG and ASVS
We scope by OWASP so the test is repeatable and does not depend on the individual tester.
- OWASP OTGv4 — broad attack-surface coverage; optionally a targeted OWASP Top 10 pass for a quick overview.
- OWASP ASVS (v4 and v5) — verification by risk level: L1 for applications without valuable data, L2 for most business applications, L3 for regulated and critical systems. ASVS v5 adds white-box verification with source code access.
Black-box, grey-box or white-box. A single module or the whole application. Not sure which level applies? We settle it on the intro call.
A report your developers can act on
An executive summary for management; a findings list ordered by severity; and for each finding a description, impact, CVSS vector, recommended fix and steps to reproduce. Every finding is peer-reviewed by a second senior tester. Once your fixes are deployed, we retest.
Every test is run by certified senior specialists — no junior hands learning on your systems.
Want to see what our report looks like? We'll send you a sample.
Use the test results toward NIS2, DORA, ISO 27001, and PCI-DSS.
Pricing
The price of a web application test depends on the size of the application, the number of roles and the chosen depth (OTG vs. ASVS level).
We'll confirm scope and price on a short call.
Our insight.
Whatever you ship to the browser, the attacker reads too — source maps, feature flags, API keys included.
Frequently asked, always answered.
Do you test in production or a staging environment?
Either. A test environment lets us go harder without operational risk; production gives the most accurate picture. We agree which on the scoping call, and where we test production we coordinate timing and have your operations team on standby.
We already scan the application regularly. Why a penetration test?
A scanner looks for known patterns in the backend. It does not know your roles, does not know that a coupon may only be used once, and never reads what is in your JS bundle. The most serious flaws tend to be where a scanner has nothing to look for.
Will you fix the problems? Can I retest once they are fixed?
We make industry best-standard recommendations for each vulnerability, but we don't implement the fix ourselves — that keeps us an independent third party, and lets us retest once your team has applied the solutions.
Do you also test single-page applications and APIs without a UI?
Yes — today that is the typical case. For SPAs we analyse the client bundle as thoroughly as the backend; for APIs we test the endpoints directly, independent of any frontend — REST and GraphQL alike.
What is the difference between a vulnerability scan and a penetration test?
A penetration test attempts to find and exploit security vulnerabilities to improve or prove the security of a system — often manually chaining one or more findings. A vulnerability scan finds known vulnerabilities but cannot combine or exploit them to further verify security.
Let's talk it through.
Tell us what you run — SaaS, portal, banking, API — and how many roles are involved. We will propose scope and level.
Book a free consultation ›