Skip to content

Legal

Security

Effective

Not yet reviewed by a lawyer

This document accurately describes what this website does today, but it has not had legal review. It should be checked by a qualified professional.

This page describes the security posture of this website and the sign-in in front of it. How the product handles resumes, job-search data, and an optionally connected mailbox is covered by its own documentation.

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.
  • Every public page is prerendered. Signing in does not change that: the pages behind the login are static too, and the guard runs before one is served.
  • 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 is one cookie, set only when you sign in. It is httpOnly, so no script on the page can read it, SameSite=Lax, and Secure in production.
  • The dynamic surface is two endpoints: signing in and out, and requesting an account. Everything else is a static file.

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.

Signing in. Input is validated against a strict schema on the server; client-side validation is treated as a convenience, not a control. Attempts are rate-limited per IP, which is what stops passwords being guessed at speed.

A wrong email and a wrong password produce the same message. Telling you which half was right is how an account list gets enumerated, and it helps nobody: someone who mistyped either one retypes both.

Credentials are read server-side only and are never sent to the browser or included in any client bundle. Error responses are deliberately generic — a failure says that it failed, not why.

Access control. The pages behind the login are guarded before they render, not by a check inside the page. A guard that runs after the page has been sent has already sent the page.

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, its sign-in, and the pages behind it.

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.