Web Application & API Penetration Testing
Deep manual testing of your application and its APIs, backed by automation and source code analysis, so the effort goes into the risks that actually matter.
Frontend and API, tested together
A modern web application is two things: the interface your users see, and the API layer behind it. Testing only one gives you a false sense of coverage.
Every CREDS web application test covers both. We test the frontend for the flaws that surface through the browser, and we test the API layer directly, including endpoints that the frontend never calls, authorisation logic that is only enforced server-side, and functionality that is reachable without going through the interface at all.
In practice, the API is where the more serious findings usually are. Broken object-level authorisation, missing access control on individual endpoints and business logic that can be driven out of sequence are not visible from the frontend, and they are not found by a scan.
Frontend
Authentication and session handling, input handling, client-side logic, access control as enforced in the interface, and the flaws that reach a user's browser.
API
Endpoint-level authorisation, object-level access control, business logic abuse, chained requests, and endpoints not exposed through the interface.
How we test
A penetration test is a time-boxed effort. That makes the real question not “what can be tested” but “where is the available time best spent”. Everything in our approach is built to answer that.
Automation does the groundwork
We run a high degree of automation across the application before and during the test: mapping the attack surface, enumerating endpoints, and clearing the ground that does not need a human. That is not the test. It is what frees our testers from repetitive work so their time goes into the findings automation cannot reach: business logic, chained vulnerabilities, authorisation flaws and abuse of the application's actual functionality.
Source code review, wherever possible
We prefer to include automated source code review in the engagement. Access to the code gives us two things: a clearer view of where weaknesses actually originate rather than only where they surface, and a significantly more efficient test, because we are not spending time inferring how the application works.
With source code analysis we dive into the code to identify potential vulnerabilities, it acts as an in-depth assessment rather than a standalone solution or replacement for security control analysis. This dual approach ensures that potential security flaws are identified and mitigated from both a structural and functional perspective.
Manual testing where it counts
Automation finds known patterns. It does not find the flaw that only exists because of how your application handles a particular business process. That work is manual, done by a tester who understands what your application is for, and it is where the majority of the engagement's hours go.
Three levels of testing
We categorise our testing into levels matched to the maturity of your application and your organisation. Which one fits depends on how often the application changes, how critical it is, and how much testing it has already had.
- 01
Baseline Penetration Test
The essential test, appropriate for every web application. Focused on identifying common vulnerabilities across the frontend and API, tested against recognised standards. The right starting point for a first test, a newly launched application, or regular recurring assurance.
Typical duration: 1 week
- 02
Advanced Penetration Test
Goes deeper, targeting sophisticated issues that a baseline test will not surface: complex attack chains, business logic abuse, subtle authorisation flaws and vulnerabilities that only appear when several smaller weaknesses are combined. Appropriate for applications handling sensitive data, or where a previous baseline test came back relatively clean.
Typical duration: 2 weeks
- 03
Scenario-Based Penetration Test
Custom scenarios built around your operational environment and threat landscape, testing what a specific, realistic attacker would actually try against your application. Appropriate when you want to answer a particular question rather than achieve broad coverage.
Typical duration: 2 to 3 weeks
Not sure which level fits? That is the first thing we work out together during scoping, and we will say so if a lighter test is the right answer.
Tested against recognised standards
Testing is only useful if its depth and breadth are verifiable. We work to international standards so that the coverage of your test is comparable, repeatable and defensible to an auditor, rather than dependent on which tester you happened to get.
OWASP ASVS. Application Security Verification Standard, our primary framework for defining the depth of a web application test.
OWASP Top 10. The baseline set of application security risks.
OWASP Web Security Testing Guide. The methodology our testers work through.
OWASP Web Service Security Cheat Sheet. Applied to API testing where relevant.
NCSC ICT security guidelines. For web applications and for Transport Layer Security (TLS).
BIO. Baseline Informatiebeveiliging Overheid, for government work.
Logius standards. For DigiD assessments.
Certifications and memberships
Nothing leaves without a second pair of eyes
Every CREDS penetration test is peer reviewed before it reaches you under our four-eyes principle, on two axes.
Technical review
A second tester examines the findings themselves: is the vulnerability real, is the impact correctly assessed, is the reproduction path accurate, and has anything in scope been missed.
Content review
A separate check on the report as a document: is each finding explained clearly enough to act on, is the risk rating defensible, is the remediation advice specific rather than generic, and will the report make sense to the developer who has to fix it and the manager who has to approve the work.
This is not an exception for large engagements. It applies to every test, at every level.
DigiD assessments, with the auditor already on our team
Organisations facing a DigiD assessment normally need two suppliers: a party to run the penetration test, and a registered IT auditor to produce the audit deliverable. Two contracts, two schedules, and a handover between them.
CREDS has dedicated registered IT auditors (RE) in house. Our RE accompanies the penetration test, works directly with the testers throughout, and produces the additional chapter that serves as input for your DigiD audit, as part of the same engagement.
We incorporate control frameworks such as DigiD into the test itself, so the testing is scoped against the requirements from the start rather than mapped onto them afterwards. The result is one supplier, one timeline, and an audit deliverable produced by someone who watched the test happen.
Relevant for DigiD, and for organisations working to BIO.
You are not waiting in the dark
A penetration test should not be a black box that produces a report three weeks later. Here is what happens while the work is in progress.
Daily start and stop notifications
You are notified when testing activity begins and ends each day, so your team always knows whether traffic against the application is us or someone else.
High-risk findings go out immediately
If we find something serious, you hear about it the moment it is confirmed, not in the report. A critical vulnerability is not something to sit on until the closing meeting.
Findings visible in real time
Findings appear in the client portal as they are raised, so your developers can begin work before the engagement is finished rather than waiting for a document.
We re-aim the test with you
A penetration test is time-boxed, which means there is always a choice about where to spend the remaining hours. During the test we brainstorm with your team about where to focus next, based on what we have found so far and what you know about the application. A finding in one area often makes a different area more interesting than the original plan assumed.
What you receive
A draft report, discussed before it is final. We walk you through the findings and the risk ratings while there is still room to correct a misunderstanding about your environment. No client should read a finalised report for the first time.
The full report. Every finding, its impact, a reproduction path and specific remediation advice.
A client abstract for your stakeholders. A separate, readable summary aimed at the people who need to understand the outcome and approve the work, not the people fixing it.
A remediation roadmap, where useful. If the findings warrant a plan rather than a task list, we will work one through with you.
Continued access to findings. Your findings stay available in the client portal, including retest requests.
Your findings, in one place
Every CREDS web application engagement comes with access to the client portal. It is where the test stops being a document and becomes something your team can work with.
Live findings
Findings are published to the portal as they are raised during the test, with impact and remediation advice attached.
Retest requests
When a fix is deployed, request a retest from the portal directly against the original finding, so the verification is recorded against the issue rather than tracked in a spreadsheet.
Ticket system integration
Findings flow into the tools your developers already work in, including Jira and ServiceNow, so remediation lives in your existing sprint process instead of a parallel one.
History across engagements
Previous tests and their findings stay available, so you can see what changed between one test and the next.
Retests are included in the engagement. Verifying that a fix actually worked costs you nothing extra.
Security that moves with your release schedule
We believe that web application testing is a collaborative journey. By partnering with you, we aim to not only identify vulnerabilities but also work together to enhance the overall security and functionality of your product. Our approach involves a continuous dialogue, where we align our testing efforts with your development cycle to ensure that security grows in tandem with your application.
We advocate for periodic testing that aligns with your development sprints and release schedule. This method allows us to systematically address new features and changes, ensuring that every aspect of your application is scrutinised for vulnerabilities before going live. This ongoing process not only helps in maintaining a robust security posture but also integrates seamlessly with agile development practices, making security a cornerstone of your product development lifecycle.
Because findings flow into your ticket system and retests are requested from the portal, recurring testing fits your existing sprint process rather than sitting alongside it.
Questions about web application testing
Do you test the API as well as the frontend?
Which level of test do we need?
Do you need access to our source code?
Is this an automated test?
Do you use the ART platform for web application testing?
How do we know the test was thorough?
What happens when we have fixed the findings?
Can findings go straight to our developers?
How long does a test take?
Can you support our DigiD assessment?
Will we hear about serious findings before the report?
Ready to test your application?
Tell us what the application does and how often it changes, and we will tell you which level of testing fits, and what it will take.