# PC Fitness — security contact (RFC 9116).
#
# Planned in docs/SECURITY.md §6 and listed in the "first month" actions at §8 item 8:
# "publish a route before you need one". This is that route.
#
# THIS FILE EXISTS TWICE, AND THE TWO COPIES ARE BYTE-IDENTICAL.
#
#   site/.well-known/security.txt          -> https://pcfitness.app/.well-known/security.txt
#   app/public/.well-known/security.txt    -> https://app.pcfitness.app/.well-known/security.txt
#
# They are two separate Cloudflare Pages projects built from two separate directories, so one
# copy reaches one host and no more. The planner's host is the one that matters most: it is
# where the accounts, the database traffic and the whole of "anything that lets one account
# reach another account's data" live, and it is the origin a researcher who finds a hole in the
# planner will look at. Publishing the contact only on the marketing site puts the notice on the
# door of the wrong building.
#
# Vite copies `app/public/` verbatim into `app/dist/`, dot-directories included — verified by
# building a public/.well-known/security.txt through Vite 6.4.3 and finding it at
# dist/.well-known/security.txt. Do not add a copy step for it; there is nothing to add.
#
# Keep the two files identical. If you edit one, edit the other in the same commit; a security
# contact that differs by host is a security contact a researcher cannot trust. Both `Canonical`
# URIs are listed below, in both copies, which is what RFC 9116 §2.6 asks for when a file is
# published at more than one address — and it is also what makes "identical" achievable.
#
# Two more things that are easy to get wrong and worth stating here rather than rediscovering:
#
#   1. `Expires` is mandatory and must be under a year out. A file past its expiry is worse than
#      no file — a researcher reads it as an abandoned project and reports to a mailing list
#      instead. Renew it, and do not set it a year out on the day you write it, because nobody
#      renews on the last day.
#   2. `Contact` is `support@pcfitness.app` and there is deliberately only ONE address for this
#      product. A `security@` alias appeared in an earlier draft of docs/SECURITY.md and nowhere
#      else; a published address that nobody has actually set up to receive mail is worse than a
#      shared one that is read.
#
# There is no PGP key and no bug bounty. Saying so is more useful than implying either exists.

Contact: mailto:support@pcfitness.app
Expires: 2027-06-30T23:59:59.000Z
Preferred-Languages: en
Canonical: https://pcfitness.app/.well-known/security.txt
Canonical: https://app.pcfitness.app/.well-known/security.txt

# The policy, in full, because a link to a longer one would be a link to a page that does not
# exist:
#
#   Good-faith research is welcome and will not be met with a legal threat.
#
#   Please do:
#     * use your own account, and test against your own data;
#     * report what you found, how you found it, and stop there;
#     * give us a chance to fix it before it is public.
#
#   Please do not:
#     * read, modify or delete another person's projects — the floor plans in this database are
#       somebody's paid work;
#     * run automated scanning or load testing against the Firebase backend. That one is not
#       just noise: Firestore is billed per operation on a free tier, so a scan is a bill, and
#       it is the single cheapest way to take this service down;
#     * social-engineer anyone, or attempt anything against the domain registrar or the hosting
#       accounts.
#
#   What is in scope: pcfitness.app, app.pcfitness.app, the Firestore security rules, and
#   anything that lets one account reach another account's data.
#
#   What is not: findings that require a compromised device, missing headers with no
#   demonstrated impact, and reports from an automated tool with no working proof.
#
#   Expect a reply within a few days. This is a personal project run by one person, not a
#   staffed security team, and setting that expectation honestly is better than missing a
#   24-hour target nobody could have met.