This page describes the security posture of this website. The PlaceMeFast product is not publicly available; when it launches it will handle resumes, job-search data, and optionally a connected mailbox, and it will have its own security documentation covering all of that.
We would rather describe what is actually true here than publish a page of reassuring language.
The attack surface, honestly
The most useful security property of this site is how little it does.
- Every page is prerendered at build time and served as static files. There is no server-side rendering per request, no template engine processing user input, and no database.
- There is no database. Nothing is persisted server-side.
- There is no authentication, no user accounts, no sessions, and no password anywhere. There is nothing to log into and nothing to steal a session for.
- There is exactly one dynamic endpoint: the early-access form handler. That is the entire server-side surface.
- There is no third-party JavaScript. No analytics, no tag manager, no advertising, no embedded widgets, no chat bubble. Fonts are self-hosted rather than fetched from Google.
- There are no cookies.
Most website vulnerabilities are vulnerabilities in things this site does not have.
How the site is protected
Transport. Served over HTTPS with HSTS, including a long max-age and subdomain coverage.
Content Security Policy. A restrictive policy is set on every response. default-src is limited to our own origin; framing is blocked entirely with frame-ancestors 'none'; object-src is none; and form submission is restricted to our own origin.
One honest caveat: the policy permits 'unsafe-inline' for scripts. The framework injects its own inline scripts, and eliminating that would require rendering every page per request, which would mean giving up static generation across the whole site. Since we load no third-party code at all, the practical risk this leaves open is narrow — but it is a real limitation and we would rather state it than let the presence of a CSP imply more than it delivers.
Other headers. X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that denies camera, microphone, and geolocation.
The form endpoint. Input is validated against a strict schema on the server; client-side validation is treated as a convenience, not a control. Submissions are rate-limited per IP. Bot submissions are filtered with a honeypot field and a timing check. Credentials for sending mail are held as environment variables and are never exposed to the browser. Error responses are deliberately generic — a failed send tells the visitor that it failed, not why, because the underlying reason would name our mail infrastructure.
Dependencies. The dependency tree is kept deliberately small, and packages that were not earning their place have been removed. npm audit reports no known vulnerabilities at the time of writing.
What we do not claim
We are a small operation building a product. We are not certified against SOC 2, ISO 27001, or any comparable standard, and we have not undergone an independent penetration test of this website.
Saying so is more useful to you than a badge would be.
Reporting a vulnerability
If you find a security issue, please tell us. We will take it seriously and we will not respond with legal threats to anyone acting in good faith.
Email the security address on our contact page. Please include enough detail to reproduce the issue, and give us reasonable time to fix it before disclosing publicly.
We ask that you do not:
- Access, modify, or delete data that is not yours.
- Run denial-of-service or high-volume automated testing against the site.
- Use social engineering, phishing, or physical attacks against us or anyone else.
We do not currently run a paid bug bounty. We will acknowledge your report, keep you updated, and credit you publicly if you would like that.
Scope
In scope: placemefast.com and its early-access endpoint.
Out of scope: the PlaceMeFast product, which is not publicly available; the infrastructure of our hosting and email providers, which should be reported to them directly; and findings from automated scanners with no demonstrated impact — particularly reports that amount to "header X is absent" without an accompanying exploit path.