Most breaches that end up in the headlines start in a web application or an API. Not with an exotic exploit: with an authorisation check performed in the browser instead of on the server, or an identifier that can be changed by hand.
What a scanner does not find
Automated tools detect patterns. The flaws that actually cost money live in business logic, and those have to be hunted by understanding what your application does:
Broken access control: reaching another user’s data by changing an identifier, or reaching administrative functions without being an administrator.
Business logic: applying a discount twice, skipping a step in a payment flow, cancelling something that should not be cancellable.
Authentication and session: weak password recovery, a second factor that can be bypassed, sessions that never expire.
APIs: excessive data exposure, missing rate limiting and undocumented endpoints that are still live.
Injection and deserialisation, where present, verified with a proof of concept.
Scope
Web applications, customer portals and intranets.
REST, GraphQL and web service APIs, with or without prior documentation.
Mobile applications for Android and iOS: static analysis, dynamic analysis and their communication with the backend.
Assisted code review, where we are given repository access: it finds more and costs less.
Methodology reference: OWASP Testing Guide and OWASP ASVS, plus tests specific to your logic.
How we work
1
Understand the application
What it does, who uses it, which roles exist and which operations are critical. Without this, logic flaws cannot be tested.
2
Mapping
Full surface: routes, parameters, endpoints and flows, including the ones missing from the documentation.
3
Manual testing per role
We test every function from every profile, including anonymous. That is where broken access control appears.
4
Exploitation and chaining
We verify real impact: which data is reached, which operation is executed and who could do it.
5
Report
With reproducible evidence and a concrete fix, not a generic recommendation your development team cannot act on.
6
Retest
We verify the fixes when your team deploys them. Included.
What you get
Technical report with reproduction steps for every finding.
Concrete remediation, written to be understood by whoever writes the code.
Executive report with the associated business risk.
Session with the development team to resolve remediation questions.
Retest and a statement of the final position.
Who does the work. The same team that audits, not an account manager. Governance, risk and compliance: CISSP, CISM, ISO 27001 Lead Auditor, ENS and Risk Analysis (CCN), certified DPO, CCSP and CDPP (ISMS Forum) and PMP (PMI). On the technical side: OSCP, CRTO II and eWPTX, ranked in the top 1% of the CCN-CERT Atenea platform. We have run compliance projects for crypto exchanges, universities and public administrations.
Questions we get asked
Do you need access to the code?
Not essential, but it helps a great deal. With repository access we find more in less time and can point to the exact line to fix. Without it we work black or grey box.
Do you test in production?
We prefer pre-production with representative data. If only production exists, we agree a window, test users and which operations are off limits.
We deploy continuously. What do we do?
A full periodic audit plus scoped reviews on every significant change. Auditing an application that changes weekly once a year gives a false sense of security.
Do you review dependencies too?
Yes. A good share of the risk in a modern application sits in third-party libraries and the software supply chain, and that is in scope.
Do not let them find it from outside first
Half an hour with an auditor to scope the audit of your application or your API.
Phone: +34 686 250 244 (Mon-Fri, 9:00 to 18:00 CET) · Email: info@jaymonsecurity.com
We reply within 2 working hours.
