Security Policy
We’re a small studio, not a security vendor, so we won’t claim certifications we don’t hold. This page is a plain account of what we actually do to protect data on our sites, and how to tell us if you find something wrong.
The short version
- 01Every site we run is served over HTTPS, and form data lands in a private database, not a public folder.
- 02Admin access is password-protected and behind a secure, HttpOnly session cookie. There are no default or hardcoded passwords.
- 03We collect only what our Privacy Policy describes, nothing more, and only our team can access it.
- 04Found a real issue? Tell us before you tell anyone else. We’ll take it seriously.
Practical, not theatrical
We’re three people running a creative studio, not a dedicated security team, and we’d rather be honest about that than dress up basic hygiene as something bigger. What follows is what we actually do, checked against what’s in our own code and infrastructure, not a template of claims we hope are true.
What’s actually in place
- All traffic to our sites is served over HTTPS. There is no plain HTTP fallback for pages that handle form data.
- Form submissions are written straight to a private database that sits behind our application, not to a public file or folder anyone could stumble onto.
- Our admin dashboards are locked behind a password, and only exist at all where a password has been explicitly set. There is no default, hardcoded, or fallback password anywhere in our code.
- Signed-in admin sessions use a secure, HttpOnly cookie, so it can’t be read by page scripts or leaked across sites, and it can’t be forged without our signing key.
- We collect only the data described in our Privacy Policy. We don’t quietly gather more just because a form makes it easy to.
- Access to client accounts, credentials, and systems is limited to the people on our team who actually need it to do the work, and is removed when a project or that person’s involvement ends.
- We don’t take or store card or payment details ourselves. Client invoicing runs through dedicated third-party payment platforms built for that purpose.
Found something? Tell us first
If you believe you’ve found a genuine security issue on one of our sites, we’d rather hear about it from you than find out some other way. Email contact@latentmedia.com with a description of the issue and, if you can, the steps to reproduce it. We’ll acknowledge a genuine report and keep you updated as we look into it and fix anything real.
We’re a small studio without a formal bug bounty programme, so we can’t promise a financial reward, but we’ll credit a responsible disclosure publicly if you’d like that, and we won’t pursue legal action against a good-faith report made in line with this page.
Testing responsibly
Please keep any testing to what’s reasonably necessary to confirm an issue exists, and:
- Don’t run automated scans or load tests that could disrupt the site for other visitors.
- Don’t access, download, or modify data that isn’t yours, including other people’s form submissions.
- Don’t test against a live client project without contacting us first.
- Give us a reasonable window to fix a confirmed issue before discussing it publicly.
The same baseline, wherever we build
For sites and systems we build and host for clients, we apply the same baseline described above: HTTPS by default, credentials handled only through channels the client has approved, and access limited to people who need it. Anything beyond that baseline, specific compliance requirements, dedicated infrastructure, or a formal security review, is scoped and agreed as part of that client’s project.
Get in touch
For a security report or any question about this page, email contact@latentmedia.com.
See also our Privacy Policy and our Terms of Service.