Web & API Penetration Testing
Manual web application and API penetration testing from Iceland team in Reykjavík. Black box, gray box, or white box engagements based on your goals. Clear reporting and support after delivery.
How we test Web Applications and APIs
Why this matters
Web applications and APIs hold your business logic and data. Failures in authorization, session handling, or workflow controls lead to account takeover, data exposure, and abuse of high impact actions such as refunds, approvals, and tenant switching.
Our approach
We run a hands on manual test aligned with OWASP Top 10, OWASP ASVS, and the OWASP API Security Top 10. We map roles and trust boundaries, then actively tamper with parameters, cookies, headers, and API payloads to hit real attack paths and edge cases.
How we help
We test authentication and session handling, including MFA flows, password reset, token lifecycle, and cookie behavior. We verify authorization across roles and tenants, focusing on IDOR patterns and API authorization issues such as BOLA and BFLA. We probe input handling for exploitable injection and client side issues, including SQL Injection, XSS, SSRF, deserialization, and unsafe file upload paths. We exercise business logic to find workflow bypasses and abuse paths, including rate limit gaps, step skipping, and unsafe state changes.
Deliverables
You receive an executive summary and a technical report with severity rated findings, affected endpoints, reproduction steps, and evidence such as request and response samples. We stay available after delivery to clarify findings and validate fixes.
Core Capabilities
OWASP Top 10 Coverage
We rigorously test for the most critical web security risks, including Injection flaws, Cryptographic Failures, and Server-Side Request Forgery (SSRF).
API Logic Assessment
APIs are the new frontier of risk. We test for specific API vulnerabilities (OWASP API Top 10), ensuring that one user cannot request or modify another user's private data (IDOR).
Business Logic Testing
Scanners can't find logic holes. We manually test scenarios like "can I buy a $1,000 item for $1?" or "can I skip the payment step?" to ensure your workflows are watertight.
Authentication & Session Attacks
We attempt to bypass your login mechanisms, testing for weak password policies, predictable session tokens, and flaws in multi-factor authentication (MFA).
Developer Friendly Reporting
Each finding includes affected endpoints or flows, evidence, clear reproduction steps, and practical remediation guidance aligned to your stack. We stay available after delivery to clarify findings and validate fixes.
Engagement Options
Black box
You provide target URLs and scope boundaries. We approach the application as an external attacker would, focusing on discovery, exposed functionality, and unauthenticated attack paths. Black box is a good fit when you want a realistic external view or when test accounts and documentation are not available.
Gray box
You provide test accounts for key roles, relevant URLs, and any available API documentation. This is the default for most web and API engagements because it gives strong coverage of authenticated features and role boundaries without slowing down delivery. Gray box is the best balance of depth and time spent per test day.
White Box
You provide everything from gray box plus technical context such as architecture notes, data flow details, and access that helps us understand intended authorization and business rules. When source code or detailed design documentation is available, we use it to focus testing on high risk areas, reach hard to exercise paths, and speed up root cause confirmation. White box is the best fit when you want maximum depth and faster engineering feedback.
Key Benefits
- Authorization coverage: Catch authorization gaps across roles and tenants before they become IDOR, BOLA, or privilege escalation issues.
- Workflow abuse resistance: Reduce risk in high impact workflows such as payments, refunds, approvals, onboarding, and account recovery through targeted business logic testing.
- Exploit focused input testing: Find real injection and input handling flaws in web and API layers, including SQL Injection, XSS, SSRF, deserialization, and unsafe uploads.
- Developer ready output: Provide developer ready findings with clear reproduction steps, request and response evidence, and fixes that map to your stack and architecture.
FAQ
What is included in a web and API penetration test?
We test the web application and its APIs with a focus on authentication, authorization, session handling, input validation, and business logic. We cover common classes of issues and also validate how real user roles and workflows can be abused through the UI and API.
Which testing approach do you use: black box, gray box, or white box?
We support all three. Gray box is the default for web and API testing because it enables role based coverage and deeper business logic validation. Black box is used when you want an external attacker view or when accounts are not available. White box is used when you want maximum depth and you can provide technical context, and in some cases code or design documentation.
How do you test APIs specifically?
We map endpoints, authentication mechanisms, and authorization rules, then validate access control across roles and resources. We also test request validation, token handling, rate limiting where relevant, and logic flaws that can be triggered through direct API interaction.
Do you test business logic and workflow abuse?
Yes. Business logic is a primary focus. We test role based flows, step skipping, state manipulation, replay scenarios, and abuse cases that scanners miss, especially around transactions and sensitive workflows.
Do you rely on automated scanners?
No. Automated tools are used for discovery and support tasks, but the core testing is manual. Manual validation is required for authorization issues, workflow abuse, and logic flaws.
What do you need from us before the test starts?
The exact inputs depend on the approach. For black box testing, we need the target URL and a clear description of the environment so we avoid impacting production, including whether the scope is production or a dedicated test environment. For gray box testing, we need test user accounts for key roles, a list of relevant API endpoints, any available API documentation, and basic technical context such as the tech stack and authentication model. For white box testing, we need everything from gray box plus access to the source code so we can validate implementation details, focus testing on high risk paths, and confirm root causes faster.
What do we get after the test is completed?
You receive a report with an executive summary, severity rated findings, evidence, clear reproduction steps, and remediation guidance. We stay available after delivery for clarification and validation of fixes.
Can you retest after we fix issues?
Yes. Retesting validates that fixes are effective and that changes did not introduce new issues. Retest scope is agreed based on the findings and the changes made.
Do you test third party integrations and external dependencies?
If they are in scope and reachable from the application, we assess how they impact security, such as OAuth flows, webhooks, SSO, and embedded components. We do not test third party providers outside your control unless explicitly agreed.
Can you test production systems?
Yes, but it depends on risk tolerance and operational constraints. In most cases a staging environment is preferred. If production testing is required, we agree on timing, monitoring, and safety controls during scoping.
How do we get a quote quickly?
Use the scoping form. Once we have the scope details, roles, and environment information, we reply within 24 hours with scope confirmation and a quote.