Reporting a security issue

How to report

Use the security form. It reaches the security queue directly, it is private, and it gives you a reference number you can quote if you need to follow up.

If you would rather write, security@playpredixn.com reaches the same people. The form is still the better route for anything with steps, requests or a proof of concept, because it returns a reference and keeps the detail out of a mail hop — but nobody with something urgent to tell us should have to fill in a form first.

Please do not send a vulnerability report to any other address. The advertising, privacy and general contacts are read by people who cannot action it, and a report sitting in the wrong inbox is a report nobody is working on.

RelatedReport a vulnerability

What to include

The more of this you can give us, the faster it gets fixed:

• The affected component — a URL, an API route, a page, or the part of the product it shows up in.
• What the issue is, in one or two sentences.
• Steps that reproduce it, written so someone else can follow them.
• What an attacker could actually achieve with it.
• Anything that helps: a request, a response, a screenshot, a proof of concept.

Please do not send us credentials, session cookies, reset links or another person’s data. We do not need them and we would rather not store them.

Scope

In scope: the Predixn web application, its API, its authentication and session handling, its authorization boundaries, its public forms, and anything that lets one account reach another account’s data.

Out of scope: our hosting provider, our email relay and our sports data provider — report those to them directly. Also out of scope are findings from automated scanners with no demonstrated impact, missing hardening headers with no exploit, rate limiting on a route where it is not a control, and social engineering of our team or our users.

How to test

Testing is welcome within these limits, and only within them:

• Use your own account and your own data. Do not access, modify or retain anything belonging to another person.
• If you do reach someone else’s data by accident, stop immediately, do not save it, and tell us what you saw so we can measure the exposure.
• No denial of service, no load or stress testing, no spam, no brute force against real accounts.
• No physical attacks, no social engineering of our team, no phishing of our players.
• Do not make the issue public until we have had a reasonable chance to fix it, and talk to us about timing rather than assuming it.

What we will do

• Read your report. A person, not a filter.
• Keep it private. There is no public queue and no endpoint that resolves a reference, so nothing you send is retrievable by anyone else.
• Tell you what we found, and tell you when it is fixed.
• Credit you if you want it and the finding is real. Ask, and we will not name you if you would rather we did not.
• Not pursue action against you for good-faith research that stayed within the rules above.

What we will not promise

Two things, stated plainly rather than buried:

• There is no bug bounty. We do not pay for reports, and we are not going to imply otherwise by leaving it unsaid.
• We are not offering a blanket legal safe harbour. What is written above is what we commit to; anything broader is a promise only the company and its lawyers can make, and we will not fake one.

If that is not enough for you to want to report something, we would still rather you told us.

security.txt

The machine-readable version of this page is served at /.well-known/security.txt. It lists security@playpredixn.com first and the reporting form second — RFC 9116 reads that order as our order of preference, and for an automated scanner or a first message the mailbox is the lower-friction one.

Relatedsecurity.txtReport a vulnerability