Security & Responsible Disclosure

Email security@sceneonhe.com. Please include what you found, how to reproduce it, and what an attacker could do with it. If you want to encrypt, ask for our key in the first message.

Do not open a public issue, post it publicly, or test against real buyers' data. Use your own accounts. If you believe real user data is exposed, stop and email us — we will prioritise it and we will tell you what we find.

We aim to acknowledge within 3 working days and to give a fix timeline within 10.

If you act in good faith under this policy, we will not pursue legal action against you for accessing the system as part of your research. We will not report you to authorities for revealing a vulnerability. We will say publicly that we worked with you, unless you would rather stay anonymous.

This does not extend to extortion, to accessing or copying another person's data, to degrading the service, or to anything done for personal gain.

Each ticket carries a signed payload. The signature is produced with a key that never leaves our servers, so a ticket's QR code cannot be manufactured off-platform and will not verify if it is altered.

The QR code shown in a buyer's wallet rotates. A screenshot of someone else's code stops matching within the rotation window, which is what makes photo-sharing at the gate unreliable. A ticket is consumed once: the first valid scan spends it, and a second scan of the same ticket is reported as a duplicate with the time and gate of the first.

The scanning app stores its offline queue on the device and never serves a cached API response — a scan verdict is a money decision and must not come from a stale cache.

Only one live payment attempt can exist for an order, and only one attempt per order can ever succeed. Both are enforced by unique indexes in the database, not by the checkout interface, so a double-click, a retry or a second tab cannot produce a second charge.

Prices are computed on our server from the published rate card. Your browser never sends an amount — there is no amount field in the request to tamper with.

Every money-moving action — manual settlement, refund approval, fee changes — is written to an audit log with the identity of the person who performed it.

Row-level security in the database constrains every query to what the signed-in person is allowed to see. A crafted request from one organiser's account cannot read another organisation's orders, settlements or documents.

Identity documents (CNIC, NTN certificate, bank letter) are held in a private storage bucket, accessible only to the owning organisation and the staff reviewers, with no public URL. System-level credentials that can bypass row-level security are server-only and are checked in CI on every change — a build fails if one is ever referenced from browser code.

Access to the platform admin surface is restricted to staff, and every view of money data there is recorded.

We would rather list these than let you discover them:

• Multi-factor authentication is not yet enforced on organiser accounts. It is planned and tracked; until it is live, use a unique password and a password manager.
• No external penetration test has been performed yet. This page will say so until one has.
• Card payments are not live. No payment provider is connected while merchant onboarding is incomplete, so the card data path described above is not yet carrying real traffic.
• Bug bounty: we do not yet pay bounties. We will credit researchers who ask.

We will determine what was accessed, tell affected users what specifically was involved, tell the relevant authority where the law requires it, and publish what happened and what changed. We will not describe a breach in a way that makes it sound smaller than it was.