Security & Vulnerability Disclosure

Email mikail@flypify.com. Please include enough for us to reproduce it:

1. What the issue is, in one or two sentences.
2. The exact URL, endpoint or app screen where it appears.
3. Steps to reproduce, or a short proof of concept.
4. What an attacker could actually do with it.
5. How you would like to be credited, if we fix it and you want to be.

Write in whatever detail you have. A rough report with a working reproduction is far more useful than a polished one without.

These are ours, and reports about them are welcome:

• flypify.com and its subdomains, including the web dashboard and the Ad Studio.
• Our public API and MCP endpoint.
• The Flypify mobile app.

These are not, and we cannot authorise testing against them:

• Third-party services we integrate with — payment processing, hosting, the commerce platforms and the ad and product sources. Report those to their own programmes.
• Findings from automated scanners with no demonstrated impact — a missing header, a version banner, a TLS configuration rated less than ideal. Show us what it lets someone do.
• Social engineering of our staff, our customers or our suppliers.
• Physical attacks, and anything requiring access to an unlocked device.

The point of these is that a researcher and an attacker should be distinguishable from the outside. Staying inside them is also what the safe harbour in section 5 is scoped to.

• Use your own account and your own data. If a bug exposes someone else’s, stop as soon as you have confirmed it.
• Take the minimum needed to prove it. One record is a proof of concept. A database is an incident.
• Do not degrade the service. No denial of service, no load testing, no bulk automated traffic against production.
• Do not modify or delete data that is not yours, and do not leave anything behind — no test files, no persistent payloads.
• Give us a chance to fix it before you publish. Tell us what your disclosure timeline is and we will work to it rather than argue with it.

• A human reply, not an autoresponder, telling you we have it and whether we could reproduce it.
• An honest assessment — including “we do not think this is a problem, and here is why”.
• A fix, or a written reason we are accepting the risk, and notice when it ships.
• Credit on this page if you want it, and none if you do not.

How quickly we commit to acknowledging a report: 3 business days. That is a commitment to reply, not to have fixed it. We do not commit to a fix date — with a team this size, a date we promised you is a date we would break, and we would rather tell you what we actually know when we know it.

We do not currently run a paid bug bounty. Nothing on this page offers or implies a payment, and we would rather say so plainly than let you spend a weekend expecting one.

A researcher who has to weigh a lawsuit against telling us has an obvious incentive not to write, so this is the term that decides whether this page works at all.

So here is ours, in the standard disclose.io wording rather than something we drafted ourselves. If you conduct vulnerability research according to this policy, we consider that research to be:

• Authorised in view of any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy.
• Authorised in view of relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls.
• Exempt from restrictions in our Terms of Service that would interfere with conducting security research, and we waive those restrictions on a limited basis.
• Lawful, helpful to the overall security of the internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If a third party brings legal action against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with it.

If you are not sure, ask before you go further. Write to the address in section 1 and describe what you want to try. A question costs you an email and settles whether this section covers you.

• Content that infringes your rights — that is a takedown, and it has its own channel and its own timeline at Copyright & Content Removal.
• A question about your own data — access, correction or deletion is covered by the Privacy Policy.
• A billing problem — see the refund policy.
• An account you think has been compromised — write to the address in section 1 and say so in the subject line. That is an incident, not a report, and we treat it as one.

No reports have been published here yet. When one is fixed and the reporter wants credit, their name goes here.