Parcelo (demo): Program guidelines

Parcelo (demo) — Parcelo (demo) is a fictional delivery and parcel-tracking service where customers sign in to see their addresses, orders and tracking. This is fictional demonstration data; the .example domains are not real.

About this program

Parcelo (demo) is a fictional delivery and parcel-tracking service where customers sign in to see their addresses, orders and tracking. 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. Tracking a parcel, changing a delivery address and reading past orders all sit behind the account; we most want reports where a tracking link or an identifier reveals someone else's address or lets their delivery be redirected.

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

This is a vulnerability disclosure program: there is no cash reward. Valid reports earn reputation and a public thank-you on the Thanks tab, and we credit you on any coordinated disclosure.

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.