Web and API testing

In a mature application, the vulnerability that costs you is rarely a reflected XSS that any scanner can find. It’s the chain: a seemingly harmless direct object access, plus a poorly designed password reset flow, plus an undocumented API endpoint left behind — three “medium” issues that, together, give away your customers’ accounts. Scanners don’t see chains, because they don’t understand what your application does. That’s where a tester’s experience works, not a checklist.

How we approach testing

We don’t start from a list of payloads — we start from the application. Who are the users, what roles exist, what data is valuable, what flows move money or identities. From that we build a threat model, then test each role — authenticated and unauthenticated — trying to do exactly what shouldn’t be possible: view another client’s data, skip a payment step, escalate from user to administrator.

We automate the repetitive parts (discovery, fuzzing, configuration checks), but validation and chaining remain manual. A scanner tells you a parameter “looks” injectable; we confirm, exploit in a controlled manner and show you what an attacker ends up reading or modifying.

What we test

The technical methodology follows the OWASP Web Security Testing Guide (WSTG), supplemented for APIs with the OWASP API Security Top 10 and verified against ASVS:

• Authorisation — the most common source of alarm: direct object access (IDOR / BOLA), broken function-level authorisation (BFLA), path traversal, horizontal and vertical escalation. We test systematically, object by object, role by role.
• Authentication and session — credentials in transit, predictable password resets, brute-force lockout, session fixation and expiry, JWT token management and signing, MFA bypass.
• Business logic — flow bypass, race conditions (for example, duplicating a transaction), abuse of legitimate functionality, price or quantity manipulation.
• Injection — SQL and NoSQL, command, template (SSTI), XXE, SSRF, request smuggling, insecure deserialisation — not just detection, but the real impact.
• Data exposure, configuration and deployment, weak cryptography, client-side (CORS, clickjacking, DOM, WebSocket).

For APIs we insist on what’s specific: for GraphQL, introspection and nested queries that exhaust the server; for REST, mass assignment and excessive property exposure; across the board, missing rate limiting and “phantom” endpoints — old or undocumented versions left in production that don’t appear in any schema.

How it runs

We follow PTES and NIST 800-115: scope and threat model → mapping and role understanding → authenticated and unauthenticated testing → exploitation and chaining → report. We choose Black-Box, Grey-Box or White-Box depending on how much information you provide — the more you share, the deeper we cover the logic, not just the surface.

What you get

• An executive summary that translates risk into business language, for management
• Each finding with a CVSS score, evidence (request/response pairs, screenshots, PoC), concrete impact and remediation steps
• Severity placed in your context, not a score detached from reality
• A remediation priority order, ranked by exploitability
• Retesting after you fix and a presentation session, technical and executive