Access between customers
Access to individual objects and isolation between customers: can a user read or change another customer's information?
02 / AI-driven pen-test
AI-driven testing.
Understand the risks.
AI-driven pen-test of web applications and APIs. AI helps us explore possible attack paths within the agreed test scope. Our specialists direct the testing, validate findings and assess the consequences.
01Web applications and APIs
02Agreed objectives and rules of engagement
03Validation and documented impact
This is what we review
Attack paths that
matter to you.
We start with the important data and functions and choose checks that fit the system and the objectives of the engagement.
Roles and administration
Can an ordinary user reach functions that should require higher privileges?
Authentication and sessions
How authentication, access tokens and sessions work, from sign-in to sign-out and expired validity.
Business logic and data flows
Flows where a technically valid request can bypass a rule, disclose information or cause unintended impact.
Input and API calls
Relevant tests of how requests, parameters, files and external references are handled.
Exposure and configuration
Settings that can be checked from the outside, error messages and reachable interfaces. Infrastructure testing is added when it is explicitly in scope.
Active testing requires an approved scope and rules of engagement. Write tests, load testing, external services for registering call-backs and production impact are included only when they are explicitly agreed.
Your deliverable
Results you can
act on.
A test result should explain what was actually shown, why it matters and what remains. A named assessor stands behind the assessment.
- An assessment for technical teams and managementPrioritised findings and a summary of the consequences the testing has demonstrated.
- Test steps that can be repeatedRelevant test steps and evidence for validated findings, with regard for sensitive information.
- A clear account of the test scopeWhat was tested, which checks did not give an unambiguous result, and what was outside the engagement.
- Remediation and retest criteriaRecommendations and a clear expected result when the same weakness is checked again.
EXAMPLE / OBJECT AUTHORISATIONThe same object.
The same object.
Two different identities.
Owner → 200 · expected access
Another customer → 200 · the object is returned
Anonymous → 401 · access denied
Another customer → 200 · the object is returned
Anonymous → 401 · access denied
VALIDATIONCheck who the object belongs to and who should be allowed to read it. An HTTP status is not enough as evidence.
VERIFIED FIXED WHENAnother customer is denied the object, while the owner still gets the intended access.
SYNTHETIC EXAMPLE · NOT A CUSTOMER RESULT
How it works
From a security question to a verified result.
Objectives and authorisation
We document systems, environments, test accounts, permitted activities and lines of contact.
Test in rounds
We run checks and probe selected attack paths. The results steer what we investigate next.
Verify and assess
We check access rules, evidence and consequences, and separate confirmed weaknesses from suspected ones.
Deliver and follow up
The result is walked through. After remediation, a bounded retest can be ordered.
Good to know
Before your
first engagement.
Do you need access to the source code?
A pen-test can be carried out without source code. Code access can add further understanding when it is in scope; a separate code review can also be combined with the testing.
Can you test in production?
The test environment is chosen together. Production requires an explicit agreement on activities, risks, timing and the rules for aborting the testing.
Is the test a one-off or ongoing?
Both arrangements can be agreed. A bounded review suits the run-up to a launch. The strength of our approach, however, is ongoing testing: confirmed findings become re-runnable checks that can run at every release, so a change that reintroduces a weakness is caught early and you see a trend over time.
Is a retest included?
The scope and price of a retest should be stated in the proposal. The retest checks the effect of the remediation against documented criteria; it is not a guarantee that the whole system is secure.
Does the testing support DORA and other requirements?
Yes. The assessment, the evidence and the retest trail become part of the documentation you need for, for example, DORA (ICT risk and operational resilience), NIS2 and ISO 27001. A named assessor stands behind the result; it is evidence and assessment, not a formal certification.
Take the next step
Which attacks does
your system need to withstand?
Tell us about the system, its most important assets and your timeline.