Security at FaceSearch

What protects your upload?

• The photo is checked and re-encoded on the server before anything else sees it. The file type is verified from its bytes, not its name, and the image is rewritten, which strips EXIF metadata such as location and camera details. Only the clean image goes on to the search.
• The upload is used for your search and nothing else. It is never sold and never used to build a face database. A signed-in user can keep the scan in their history and delete it at any time; a guest search keeps nothing. Details are on privacy by design.
• Results are visible only to you. There are no public result pages and no shareable links to someone else's scan.

What protects your session?

• Transport encryption. The site is served over HTTPS and sends a Strict-Transport-Security header, so browsers refuse to connect over plain HTTP.
• Session cookies the browser cannot read. Sign-in tokens are stored in sealed, httpOnly, secure, same-site cookies set by the server. Page scripts never see them, which takes the usual token-theft routes off the table.
• No secrets in the browser bundle. Backend keys and server credentials stay on the server. The browser receives only the public configuration it needs to show the page.
• Security headers on every response. A Content Security Policy, frame denial, a referrer policy and content-type sniffing protection are set once and applied to every page.
• Bot checks on the free search. The first free search runs after a short browser check, which keeps automated abuse of the free allowance down and protects the index from scraping.

What protects your payment?

FaceSearch never sees or stores card numbers. Web subscriptions are processed by Stripe through RevenueCat; app subscriptions are processed by Apple and Google. We hold the subscription status and plan, nothing more. Cancelling, refunds and payment-method changes happen with the provider you paid, as the billing FAQ explains.

How do I report a vulnerability?

The site publishes a security.txt file in the standard location (the .well-known directory, per RFC 9116) that names the contact and is kept current. Send reports to contact@facesearch.cc with the subject "Security". A person reads every report; we acknowledge within five business days, confirm whether we can reproduce the issue, and tell you when it is fixed. We thank researchers by name in the acknowledgement if they want that, and we do not pursue people who report in good faith.

1. 1

   Describe the issue

   What you found, where (URL, endpoint or app screen), and the impact you believe it has. One issue per report keeps things clear.

2. 2

   Show how to reproduce it

   Steps, requests and responses, or a short recording. Redact any personal data of other users that you came across; do not include it.

3. 3

   Tell us how to reach you

   An email address we can reply to, and whether you want to be credited in the acknowledgement.

4. 4

   Give us time to fix it

   We ask for 90 days before public disclosure, or less if the fix ships sooner. We will tell you the fix date so you can plan a write-up.

What we ask researchers not to do

Is there a bug bounty?

Not at the moment. There is no paid programme and no promise of a reward. What we offer is a fast, human response, a fix, and public credit if you want it. If that changes, this page and the security.txt file will say so.

Incidents

If a security incident affects your data, we tell affected users by email and notify the authorities the law requires, within the deadlines the law sets. Questions about a suspected incident go to contact@facesearch.cc. Account and billing questions that are not security matters go to support.