Security and responsible disclosure

Briefly, because it affects what is worth testing: this is a static marketing site. It has no user accounts, no login, no database, and no personal data at rest beyond enquiries sent to us by email.

• Contact form submissions are validated on the server before anything is done with them.
• Client IP addresses are hashed with a secret salt before being used for rate limiting. The raw address is never written to our storage.
• Secrets live in environment variables. A build fails if a variable name that would be exposed to the browser looks like it holds a credential.
• Dependencies are kept deliberately few, so there is less to go wrong and less to keep patched.

In scope:

• This website and the domain it is served from.

Out of scope:

• Any client system. If you have found something in software we built for someone else, tell us and we will pass it on — but do not test it.
• Third-party services we use. Report those to the provider directly; we will help you find the right contact.
• Findings from automated scanners with no demonstrated impact.
• Missing hardening headers, or missing rate limits, with no demonstrated impact.
• Reports that a version number is out of date, without a working exploit path.
• Social engineering of our people, and anything requiring physical access.

Good faith means:

• You follow this policy, and stop as soon as you have proved the issue exists.
• You do not access, modify, delete or exfiltrate anyone's data. If you encounter personal data, you stop immediately and tell us.
• You do not degrade the service for anyone else — no denial-of-service testing, no brute-forcing, no automated scanning at volume.
• You give us reasonable time to fix the issue before telling anyone else.
• You do not use the finding to extract payment.

If you are unsure whether something is within this policy, ask first. We would rather answer a question than argue about it afterwards.

Email contact@littlestone.world.

It helps enormously if you include:

• What the issue is, and what an attacker could actually do with it.
• Clear steps to reproduce it.
• The URL or component affected.
• Anything supporting it — a request and response, a short screen recording.
• How you would like to be credited, if you would like to be.

We will acknowledge your report within 3 working days, tell you our assessment and rough timeline once we have looked, keep you updated while we fix it, and tell you when it is resolved.

Machine-readable contact details are published at /.well-known/security.txt in the format defined by RFC 9116.

We do not run a bug bounty and we do not pay for reports. That is worth knowing before you spend your time, rather than after.

What we do offer is a real response from a person, a fix, and public credit if you want it.

We would ask you to hold off publishing until a fix is out, or for 90 days, whichever comes first. If a fix will take longer than that we will tell you why and agree a date with you rather than simply asking for more time.

We will not ask you to keep a finding secret indefinitely, and we will not treat a disclosure after an agreed date as a breach of this policy.

The "last updated" date moves whenever this content does. The expiry date in security.txt is checked automatically, and the build fails when it comes within thirty days — an expired security.txt tells a researcher the contact is stale, which is worse than not publishing one.