14 scenarios · Applications, identity & cloud
A misleading link, a missing permission check or an overly permissive configuration: see how risks can arise in business software and which defences to examine.
Fictional learning examples. The checks describe criteria to test within an authorised scope, not audit results or client incidents.
An employee receives a sharing invitation that imitates a familiar tool. The link leads to a page designed to capture their credentials.
A portal accepts many sign-in attempts against the same account. Weak passwords make the risk worse.
Password reuse exposes a portal when another service is breached. Password spraying instead tries a few common passwords across many accounts.
An old reset link remains valid after a password change. Reusing it could allow account takeover.
An application uses a session cookie. An external page could trigger an email change if the server does not verify the action’s legitimacy.
A support tool displays user comments. Unsafe rendering can turn that content into browser instructions.
A search screen builds its query by concatenating user input. Unexpected input can change the data-access logic.
A signed-in user requests an invoice by ID. Without ownership and organisation checks, the API may return someone else’s document.
An API reads a token without checking which service it targets. It may accept an identity in the wrong context.
A feature imports an image from a user-supplied URL. Without restrictions, the server could contact resources not intended for public access.
A customer portal accepts supporting documents. Poor validation or public storage can expose data or introduce unsafe content.
A pipeline prints its full configuration during deployment. A key may become visible to anyone who can read the logs.
A service that only reads one file has permissions across many resources. A compromise would therefore have a wider impact than its normal purpose.
An SCA check flags a vulnerable library. The team needs to establish the affected version, how it is used and available upgrade paths.
A scenario helps frame the right question; it does not replace a review of your architecture. For each agreed check, we define prerequisites, expected evidence and stop conditions with your team.
Choose the components, dummy accounts and authorised environments. Sign-in tests are volume-limited and never target real users without explicit agreement. A phishing simulation needs its own scope; this page launches no campaign.
The forbidden case should be blocked while the legitimate workflow remains usable. Keep evidence minimal: observed behaviour, a redacted excerpt and the tested version, without passwords, real tokens or client data.
Keep the regression scenario and record anything not verified. An alert disappearing does not by itself prove a fix. The references above guide the review; they do not constitute OWASP certification.