Sample Security Report

What we found

A logged-in user could access another user's profile information simply by changing a user identifier in an API request.

What an attacker could do

An attacker with any valid account could read the personal data of other users, without needing any further privileges.

Why it matters

If exploited in a real environment, this could expose customer data and create privacy, compliance and reputational risks for the business.

How to fix it

The application should enforce authorisation on the server for every request, verifying that the signed-in user is allowed to access the resource they are asking for rather than trusting the identifier supplied in the request.

What we found

The sign-in endpoint accepts requests without throttling or lockout. During testing, 10,000 login attempts were submitted in a single hour and the application neither slowed them down nor locked the account.

What an attacker could do

With no throttling or lockout, an attacker can run credential-stuffing campaigns, automated tools that try many leaked username and password combinations, at full speed and without any limit on attempts.

Why it matters

Credential stuffing is one of the most common routes to account takeover. If an attacker succeeds, they gain the same access as the legitimate customer, including their data and the actions they can take in the application.

How to fix it

Add rate limiting and throttling to the sign-in endpoint, lock accounts temporarily after a small number of failed attempts, and monitor for unusual volumes of login failures so that a credential-stuffing campaign is detected early.