Security and Vulnerability Disclosure
How a certificate is secured, why anyone can verify one without our permission or our servers, and how to report a vulnerability to us — including a plain commitment that we will not take legal action against a researcher acting in good faith.
1. How a certificate is secured
1.1 The signature
Every certificate is signed with an Ed25519 key over a canonical JSON serialisation of its contents. Canonical means the bytes that are signed are derived from the data by a deterministic rule — key order, encoding, and whitespace are all fixed — so the same certificate always produces the same bytes, and no two different certificates can produce the same ones.
The signed payload includes, at minimum:
- the verdict the screening returned;
- the SHA-256 hash of the label photograph the screening was run against;
- which recall feeds were searched, and how fresh each one was at that moment; and
- the timestamp of the screening.
Because all of that is inside the signature, altering any of it breaks the signature. Changing RECALL MATCHED to NO MATCH FOUND breaks it. Swapping the photograph breaks it. Backdating the screening breaks it. Quietly claiming the recall data was fresher than it was breaks it. There is no field a forger can touch and leave the document verifiable.
1.2 The photograph is bound to the document
The certificate does not contain a photograph. It contains a hash of one. Anyone can fetch the image, hash it themselves, and compare. If the bytes differ by a single pixel, the hash differs, and the certificate no longer matches the image it claims to describe.
Photographs are held in content-addressed storage: the address of an image is derived from its own contents. There is no operation, available to us or to anyone else, that changes the bytes stored at a given address. To store different bytes is to create a different address, which the certificate does not point at.
1.3 Verification does not require us
Verifying a certificate is a pure function of the certificate, the photograph, and our public key. It touches no database, requires no account, needs no permission, and does not have to reach our servers at all.
That means you can verify a certificate we did not serve you — one that was emailed to you, printed, or handed over on a phone screen at a kerbside — and you can verify it after we have stopped answering the phone, changed our terms, or gone out of business.
This is the whole design. A certificate whose authenticity depends on us confirming it is worth exactly as much as our continued existence and our continued honesty. A certificate you can check yourself is worth what the mathematics is worth. We built the second kind on purpose, and it is the reason we can be sceptical about our own product on every other page of this site and still expect to be believed.
2. Payment
Payments are processed by Stripe, Inc. Card details are entered on Stripe’s own form and go to Stripe. We never receive, see, hold, or store a card number. There is no card data on our systems to steal, because there is no code path by which it could arrive.
3. Data in transit and at rest
Everything is served over TLS. The site sets HSTS, so a browser that has seen us once will refuse to connect insecurely thereafter. Traffic to our database, our storage bucket, and every sub-processor is encrypted in transit.
Label photographs have their EXIF and GPS metadata stripped on our server before they are stored or transmitted anywhere. Screening requires no account, so for a free screening there is no password to breach, no session to hijack, and no profile to exfiltrate. The strongest security control we have is the data we chose never to collect.
4. What we do not claim
We have no SOC 2 report, no ISO 27001 certificate, and no penetration-test letter to wave at you. We are a small operation and we are not going to imply an apparatus we do not have. What we have is a system with very little to steal, a verification model that does not depend on us being trustworthy, and the disclosure policy below.
5. Reporting a vulnerability
Write to security@shelfstamp.com. Include what you found, where, and enough detail for us to reproduce it. If you have a proof of concept, send it. If you would like to encrypt the report, say so and we will send you a key.
Please do not open a public issue, post it publicly, or disclose it to anyone else until we have had a reasonable chance to fix it. We will not use that request as a lever to keep it quiet indefinitely — see section 7.
6. Scope
6.1 In scope
- The ShelfStamp website and its application programming interfaces.
- Anything that lets a person forge a certificate, alter a verdict, or make a document verify that we did not sign.
- Anything that lets a person substitute the photograph a certificate is bound to.
- Anything that discloses another person’s screening, label photograph, email address, or unlisted certificate.
- Authentication and authorisation flaws, injection, server-side request forgery, remote code execution, and broken access control on business-account features.
6.2 Out of scope
- Denial of service, volumetric attacks, and resource-exhaustion testing. Do not do it. We are small enough that you will simply take the site down, and taking a recall-screening tool offline harms the people using it.
- Social engineering of our staff, our vendors, or our users. Phishing, pretexting, and support-desk manipulation are not in scope and are not welcome.
- Physical attacks against offices, hardware, or people.
- Automated scanner output with no demonstrated impact. A list of missing headers, a TLS configuration grade, a cookie without a flag it does not need, or an unexploitable version banner is not a vulnerability report. Show us the impact, or show us the path to one.
- Findings in a third-party service listed on our Sub-processors page. Report those to them; they run real programmes and can pay you.
7. What we commit to
- We will acknowledge your report within 3 business days, by a reply written by a person.
- We will tell you honestly whether we consider it a vulnerability, and if we do not, we will tell you why rather than going quiet.
- We will keep you updated on the fix, and we will tell you when it ships.
- We will agree a disclosure timeline with you. If we cannot fix an issue quickly, we will say so and give you a date rather than stalling. We will not ask you to sit on a finding forever.
8. Safe harbor
If you make a good-faith effort to comply with this policy during your research, we will consider it authorised, we will not initiate or support legal action against you, and we will not report you to law enforcement — including under the Computer Fraud and Abuse Act, 18 U.S.C. § 1030, or any state analogue.
Good faith means: you stayed within scope, you did not access, modify, or exfiltrate data belonging to anyone other than yourself, you did not degrade or interrupt the service for anyone else, you stopped as soon as you had confirmed the issue, and you reported it to us promptly and privately.
If a third party brings an action against you for research conducted under this policy and in accordance with it, we will make it known that your conduct was authorised.
This protection does not extend to a person who exfiltrates user data, degrades the service, extorts us, or holds a finding hostage. That is not research, and no one who does it will be under any illusion that it was.
9. Honest expectations, because we are small
There is no bug bounty. We have no budget for one and we are not going to pretend otherwise, then negotiate you down to a T-shirt. If you find something and you would like to be credited, tell us and we will credit you by name and link on this page, alongside the fix. If you would rather not be named, we will not name you.
There is no security team here. There is no 24-hour rotation and no on-call. In practice that means: an acknowledgement inside 3 business days is a commitment we can keep; a same-day reply at 2 a.m. is not. A serious issue — one that lets a certificate be forged or another person’s data be read — will be worked on the day we understand it. A minor issue may take weeks, and we will tell you it is taking weeks instead of leaving you wondering.
What you get in exchange for that candour is a real human reply, a real fix, and no legal department writing to your employer.
10. Contact
security@shelfstamp.com for vulnerability reports and anything security-related · support@shelfstamp.com for everything else