Aurora Pay (demo): Program guidelines

Aurora Pay (demo) — Aurora Pay (demo) is a fictional consumer payments wallet where people hold a balance, log in and send money. This is fictional demonstration data; the .example domains are not real.

About this program

Aurora Pay (demo) is a fictional consumer payments wallet where people hold a balance, log in and send money. This is a fictional program used to demonstrate the platform — the domains use the reserved .example names, so there is nothing to actually test.

What we care about most

We run every asset on the Scope tab, but we are most interested in anything that lets someone sign in as another user, stay signed in when they should not, or reach data and features that are meant to sit behind the login or a paid entitlement. The money lives behind the login at app.aurorapay.example and the REST API at api.aurorapay.example; the sign-in, step-up confirmation and device-trust flows are the parts we most want stress-tested.

Focus areas

In rough order of what we most want to hear about:

• Authentication bypass and broken authentication — reaching an authenticated area, an admin view, or another tenant without valid credentials (CWE-287, CWE-306).
• Account takeover — through the password-reset flow, the email- or phone-change flow, or a predictable or leaked credential (CWE-640, CWE-620).
• Multi-factor authentication bypass — skipping, replaying or downgrading the second factor.
• Session management flaws — fixation, sessions that never expire, tokens that survive a sign out or a password change, and predictable or improperly scoped session identifiers (CWE-384, CWE-613).
• SSO and federation misconfiguration — OAuth, OIDC and SAML flows that can be redirected, replayed, or made to accept a token they should reject (CWE-287, CWE-347).
• Broken access control and IDOR — missing authorization checks that expose or change another user's objects by changing an identifier (CWE-639, CWE-862).
• Privilege escalation — moving from a normal account to staff or admin, or across tenants, horizontally or vertically (CWE-269).
• Entitlement bypass — reaching premium, paid or tenant-restricted content without the entitlement that should gate it.
• Token validation flaws — JWTs or API tokens accepted with a weak signature, a wrong audience or no expiry (CWE-345, CWE-347).

Rules of engagement

• Test only against accounts you create yourself. Never use another person's account.
• Prove impact with the smallest possible proof of concept. Do not read, change, export or keep another user's data; a single record or a screenshot of your own two test accounts is enough.
• The moment a flaw gives you access to real personal data or someone else's account, stop and report it — do not explore further.
• No denial of service, no automated load or scanning that degrades the service, no social engineering of staff or users, and no physical attacks.
• Keep findings private until we have fixed them and agreed on disclosure.

Out of scope and ineligible

The exact systems you may test are on the Scope tab; only assets marked in scope are authorized. Reports that only restate an item on the Scope exclusions table, or that show no realistic security impact, are closed as Not applicable.

Recognition

Valid reports earn a bounty by severity (see the Rewards table) plus reputation and a public thank-you on the Thanks tab. Authentication and access-control issues that we can confirm are rated on their real impact — an account takeover or a full access-control bypass is treated as high or critical.

Coordinated disclosure

Once a report is resolved, either side can request disclosure; the other agrees, and we publish a summary (or the full report) by mutual agreement. This program follows the platform's disclosure guidelines.