Security and Vulnerability Disclosure

• Keeping card data out of our systems is the single largest reduction in risk available to a business like ours: there is no cardholder data for an attacker to steal from us.
• Payments are processed by a PCI DSS Level 1 service provider. Our own scope is limited accordingly.
• Payment processor credentials belonging to the platform are encrypted at rest with AES-256-GCM using a key held outside the database, so a database copy alone does not yield the ability to charge or refund cards.
• Payment webhooks are cryptographically verified against the processor’s signature before they are acted on, so a forged callback cannot mark an unpaid order as paid.

Accounts and access

• Passwords are stored only as salted one-way hashes using bcrypt. We cannot recover or read your password.
• Staff and organizer accounts are created by invitation only. Public registration creates a customer account and nothing more.
• Every privileged action is authorized on the server against the acting user’s role and their assignment to the event in question — never on the basis of what the browser sent.
• Sign-in, token issuance, and device enrolment are rate limited to blunt brute-force and credential-stuffing attacks.

Data

• All traffic is served over HTTPS. Data at rest is encrypted by our database and storage providers.
• Session cookies are HTTP-only, Secure in production, and SameSite-constrained, so page scripts cannot read them and they are not sent on cross-site requests.
• The Service refuses to be framed by other sites, except for the ticket widget, which is designed to be embedded and is isolated from the rest of the application.
• Exported attendee rosters deliberately exclude ticket codes, so a spreadsheet leaving the system cannot be used to fabricate entry.

Tickets and the door

• Inventory, holds, and redemptions are enforced by the database itself with conditional updates, so two people cannot buy the last ticket and one ticket cannot be redeemed twice — including under concurrent load.
• Every scan is written to an audit record naming the device, the operator, and the time. Offline scans are reconciled on reconnect, and the earliest scan wins.
• Scanner devices are enrolled with a short-lived, event-scoped credential that expires with the event access code and can be revoked at any time.

• Secrets are held in the deployment platform’s encrypted environment configuration, never in source control.
• Changes go through type checking, linting, and an automated test suite — including concurrency tests run against a real database — before deployment.
• Access to production data is limited to those who need it, and administrative surfaces are separated from the public site.
• We keep short-lived request and security logs for investigation, and audit records of privileged actions.

For where data is stored and how long we keep it, see the Privacy Policy.

• Use a password unique to this Service, and a password manager to store it.
• Verify your email address, so that a password reset actually reaches you.
• Do not post pictures of your tickets. A QR code in a public photograph can be used by whoever sees it first — see Protect your ticket.
• Tell us immediately at support@fomotickets.com if you think your account has been accessed by someone else.

We welcome reports from security researchers, and we would much rather hear from you than from an attacker.

Safe harbour

If you make a good faith effort to comply with this policy during your research, we will:

• consider your research to be authorized under the Computer Fraud and Abuse Act and comparable state law, and not pursue or support a civil or criminal action against you for it;
• consider it exempt from the anti-circumvention provisions of the DMCA, and not bring a claim against you under them;
• waive any restriction in our Terms of Use or Acceptable Use Policy that would otherwise prohibit your testing, to the limited extent of that research; and
• work with you to understand and resolve the issue quickly, and — if a third party brings legal action against you for research conducted under this policy — make clear that your activity was authorized.

This safe harbour applies only to the extent it is within our power to give. It does not authorize action against a third party’s systems, and it does not protect conduct outside the scope below.

In scope

• The public website and its checkout, on our own domains.
• The embedded ticket widget.
• Our public API endpoints and webhook receivers.
• The check-in application.

Out of scope

• Anything belonging to a third party, including our payment processors, hosting, database, email, and analytics providers. Report those to the provider directly.
• An Event Organizer’s own website, even where it embeds our widget.
• Denial-of-service, load testing, stress testing, or resource exhaustion of any kind.
• Physical attacks, social engineering, and phishing of our staff, an Event Organizer, or attendees.
• Reports generated solely by an automated scanner with no demonstrated impact, and findings whose only substance is a missing best-practice header or a software version number.
• Spam, weak password policy on your own account, and self-XSS.

Rules

1. Do not access, modify, export, or delete data that is not yours. Use your own test account and your own orders. If you encounter someone else’s personal information, stop, do not save it, and tell us in your report.
2. Do not test against a live event. Interfering with scanning or inventory while an event is selling or admitting people can leave real people outside a venue.
3. Do not run automated scanning at a rate that degrades the Service for anyone else.
4. Do not use a vulnerability beyond the minimum needed to demonstrate it, and never for personal gain — including obtaining free or discounted tickets.
5. Keep the issue confidential until we have fixed it and agreed with you that it can be disclosed.

How to report

Email support@fomotickets.com with:

• a description of the issue and its impact;
• clear steps to reproduce it, and any proof-of-concept;
• the URL, parameter, or endpoint affected; and
• how you would like to be credited, if we publish a fix note.

Please send one issue per report, in English.

What you can expect from us

• Acknowledgement within 3 business days.
• An initial assessment, with a severity and a plan, within 10 business days.
• Progress updates until it is resolved, and notice when the fix ships.
• Credit for the finding, if you want it.

We do not currently run a paid bug bounty. We may make a discretionary award for a report of genuine severity, but you should not rely on one.

If we suffer a breach affecting personal information, we will investigate, contain it, and notify affected people and the relevant regulators within the time the law requires. Our notice will say what happened, what information was involved, what we have done, and what you should do.

You can reach our security contact at support@fomotickets.com at any time. A machine-readable version of that contact is published at /.well-known/security.txt.