The attacks that actually happen.

Authentication decides who a system believes you are. When it can be guessed, reused, or skipped, every other control behind it becomes decorative.

How it works

Attackers try vendor default passwords that were never changed, credentials leaked in past breaches, weak or absent multi-factor checks, and session tokens that can be predicted or replayed. A single admin account still set to the factory password can hand over an entire platform.

Impact

Full account takeover, administrative access, and lateral movement into everything the compromised identity can reach. This is one of the most common root causes of a serious breach.

How we test

We enumerate authentication endpoints, test for default and weak credentials against known product defaults, probe session handling and token strength, and check whether multi-factor can be bypassed or downgraded.

How to defend

Force a password change on first use, ban known-breached passwords, require phishing-resistant multi-factor for privileged access, and rotate and scope every service credential.

Access control enforces what an authenticated user is allowed to do. When the check is missing on the server, the client is free to ask for anything.

How it works

The classic form is the insecure direct object reference, where changing an identifier in a request returns another customer's record. Others include privilege escalation, forced browsing to hidden functions, and trusting a role sent by the browser rather than enforced on the server.

Impact

One user reads or modifies another user's data, a standard user reaches administrative functions, and confidentiality collapses across the whole tenant base.

How we test

We test every object reference and function against multiple user roles, attempt horizontal and vertical privilege escalation, and confirm that authorization is enforced server-side on every sensitive action rather than hidden in the interface.

How to defend

Enforce authorization on the server for every request, deny by default, tie every object to its owner, and never rely on the client to hide a function it can still call.

Injection happens when user input is mixed into a command or query instead of being kept strictly as data. The system then executes the attacker's text as instructions.

How it works

In SQL injection, crafted input rewrites a database query to read, alter, or delete records, and in some cases to run commands on the host. Command injection does the same against the operating system shell.

Impact

Wholesale theft or destruction of a database, authentication bypass, and in the worst cases remote code execution on the server. Decades old, still routinely fatal.

How we test

We probe input handling with safe, non-destructive payloads to detect where input reaches a query or a shell, then confirm the class of injection without extracting or altering real data.

How to defend

Use parameterised queries and prepared statements everywhere, validate and encode input, apply least privilege to the database account, and never build a query by string concatenation.

Cross-site scripting lets an attacker run their own JavaScript in another user's browser, in the trusted context of your site.

How it works

Unescaped input is reflected back into a page or stored and served to other users, where it runs with the victim's session. Stored variants can hit every visitor to a page without any interaction.

Impact

Session hijacking, credential theft, silent actions taken as the victim, and defacement. On an admin panel it can escalate to full application compromise.

How we test

We test how the application handles special characters across inputs and outputs, distinguish reflected, stored, and DOM-based variants, and prove impact with a harmless proof marker rather than a live payload.

How to defend

Encode output for the correct context, adopt a strict Content Security Policy, use frameworks that escape by default, and treat every piece of input as untrusted.

In an SSRF attack, the attacker persuades your server to make a request on their behalf, reaching systems they could never reach directly.

How it works

A feature that fetches a user-supplied URL is coerced into calling internal services, cloud metadata endpoints, or other hosts inside the trust boundary. Cloud metadata services are a frequent target because they can hand out credentials.

Impact

Exposure of internal services, theft of cloud credentials, and a pivot point deep inside the network that bypasses the perimeter entirely.

How we test

We identify every feature that fetches a remote resource, test whether it can be redirected to internal or metadata addresses, and confirm reachability without pulling sensitive material.

How to defend

Validate and allow-list outbound destinations, block requests to private and metadata ranges, disable unused URL schemes, and require authentication on internal services rather than trusting the network.

The software may be sound, but the way it is deployed leaves the door open. Misconfiguration is exposure created by settings, not by code.

How it works

Common cases include default accounts left enabled, verbose error pages that leak internals, management interfaces exposed to the internet, permissive CORS, missing security headers, and development settings left switched on in production.

Impact

Information disclosure that maps the attack for an adversary, direct access to admin tooling, and a chain of small mistakes that add up to a full compromise.

How we test

We review headers, error handling, exposed interfaces, cloud storage permissions, and cross-origin policy across the estate, and flag every setting that widens the attack surface.

How to defend

Harden to a known baseline, remove defaults, separate production from development configuration, and treat configuration as code that is reviewed and version-controlled.

Secrets are the keys to the kingdom. When they sit in a place anyone can read, no attack is even required.

How it works

API keys, passwords, and tokens end up hardcoded in client-side JavaScript, committed to public code repositories, printed in logs, or returned in API responses. Sensitive data is often transmitted or stored without proper encryption.

Impact

Direct access to paid services, cloud accounts, and databases using your own keys, plus regulatory exposure when personal data is left unprotected.

How we test

We harvest client-side code and public sources for exposed keys and tokens, check transport and storage encryption, and identify sensitive data returned where it should not be.

How to defend

Keep secrets out of code and out of the browser, load them from a managed secret store, rotate anything exposed immediately, and encrypt sensitive data in transit and at rest.

Modern applications are mostly other people's code. A single outdated library with a public exploit can undo an otherwise careful build.

How it works

A dependency, framework, plugin, or server version with a known CVE is left unpatched. Attackers scan for the fingerprint of the vulnerable version and fire a ready-made exploit.

Impact

Remote code execution, data theft, or full server compromise, often through a component the team forgot was even installed.

How we test

We fingerprint versions across the stack, cross-reference them against public vulnerability databases, and confirm exploitability rather than reporting a version number alone.

How to defend

Maintain an inventory of components, subscribe to advisories, patch on a schedule, and remove anything you do not use. Most exploited flaws already had a fix available.

APIs are the plumbing behind every modern application, and they are increasingly the primary attack surface. An API blueprint left open hands an attacker the whole floor plan.

How it works

Endpoints returning more data than the interface shows, missing authorization on individual objects, unauthenticated documentation such as Swagger or WADL, and rate limits that never existed. Automated clients then harvest at scale.

Impact

Mass extraction of personal and financial records, abuse of business logic through direct API calls, and enumeration of an entire user base.

How we test

We discover documented and undocumented endpoints, test authorization on each object and action, look for data returned beyond what is needed, and check for rate limiting and abuse protection.

How to defend

Require authentication and per-object authorization on every endpoint, return only the fields the client needs, remove public documentation of private APIs, and rate-limit aggressively.

CSRF tricks a logged-in user's browser into performing an action they never intended, using the trust the site places in their session.

How it works

A malicious page causes the victim's browser to submit a request to your site while they are authenticated. Without a check that the request was intentional, the server carries it out.

Impact

Unwanted state changes made as the victim, from changing an email address to moving money, all without the attacker ever seeing the session.

How we test

We test whether sensitive actions require an unpredictable anti-forgery token, whether that token is validated, and whether cookie and same-site settings defend the session.

How to defend

Require anti-forgery tokens on state-changing requests, set cookies to SameSite, and re-authenticate for the most sensitive actions.

Some of the most damaging attacks break no technical rule at all. They abuse the intended logic of the application in a way the designers never considered.

How it works

Examples include skipping a step in a checkout to avoid payment, replaying a one-time action, manipulating quantities or prices, or exploiting a race condition to redeem the same credit twice.

Impact

Direct financial loss, fraud, and reputational damage, none of which a scanner will ever detect because nothing is technically malformed.

How we test

This is where human testers earn their fee. We model how the application is meant to work, then deliberately misuse each workflow, sequence, and assumption to find where the logic gives way.

How to defend

Design workflows with explicit server-side state, enforce every business rule on the server, guard against replay and race conditions, and threat-model new features before they ship.

The most reliable way into a hardened network is often the person using it. Social engineering targets people, not code.

How it works

Attackers send convincing emails, messages, or calls that trick a user into revealing credentials, approving a multi-factor prompt, or running a malicious file. It remains one of the most common entry points for serious breaches.

Impact

Stolen credentials, an approved login from an attacker, or malware on an internal machine, any of which becomes the foothold for everything that follows.

How we test

Where authorised, we run controlled phishing simulations and awareness exercises, and we test the technical controls that limit the damage when someone does click.

How to defend

Deploy phishing-resistant multi-factor, filter and flag inbound mail, rehearse the response, and build a culture where reporting a mistake is fast and blameless.

Ransomware turns your own data against you, encrypting it and demanding payment. Modern operators steal the data first, so paying does not undo the exposure.

How it works

Attackers gain a foothold, often through phishing or an exposed service, move laterally, escalate privileges, exfiltrate sensitive data, and then encrypt systems across the estate to force a payment.

Impact

Operational shutdown, permanent data loss, extortion, and public disclosure of stolen records. For a small institution it can be existential.

How we test

We assess the paths an intruder would use to reach and spread, the exposure of remote-access and backup systems, and the resilience of your recovery plan, rather than deploying anything destructive.

How to defend

Segment the network, secure and test offline backups, restrict remote access behind multi-factor, patch exposed services, and rehearse recovery before you need it.

A denial-of-service attack does not steal data. It takes away availability, which for a bank or a booking platform is its own kind of theft.

How it works

Attackers flood a service with traffic or trigger an expensive operation repeatedly until legitimate users cannot get through. A single unbounded query or file upload can be enough.

Impact

Downtime, lost revenue, and reputational damage during the outage, sometimes used as cover for a second attack.

How we test

We identify resource-intensive operations and missing limits that an attacker could weaponise, and we assess architectural resilience, without launching a live flood against production.

How to defend

Rate-limit and cap expensive operations, put a CDN or scrubbing layer in front of public services, and design for graceful degradation under load.

You can secure your own code perfectly and still be breached through a supplier, a dependency, or an update you trusted.

How it works

Attackers compromise a third-party library, a build pipeline, or a vendor with access to your systems, then ride that trust inward. A poisoned update reaches everyone who installs it.

Impact

Widespread, hard-to-detect compromise that arrives through a channel you deliberately trusted, affecting every downstream user at once.

How we test

We review third-party integrations, the provenance of dependencies, and the access granted to vendors and build systems, and we flag trust that is broader than it needs to be.

How to defend

Vet and limit vendor access, pin and verify dependencies, monitor your build pipeline, and apply least privilege to every integration.