BlaronStart a project

Security

This page describes how this website and the systems behind it are actually built. It is deliberately limited to measures that are in place today, rather than aspirations or certifications we do not hold.

In transport

  • The site is served over HTTPS. Plain HTTP and non-canonical hostnames are redirected to the canonical HTTPS address in a single hop.
  • The application is served by a single hardened process, with static pages prerendered rather than assembled in the browser.

Third-party code

  • Nothing in an optional category loads before you allow it. Decline analytics and the script is never fetched.
  • Fonts are self-hosted, so no request leaks to an outside font provider.
  • No advertising networks, no session recording, no heatmaps, no social tracking pixels.
  • The list of providers we do use is published on our Sub-processors page.

The inquiry assistant

  • It answers only from published site content, and is instructed not to invent facts.
  • Sessions are held in memory with a fixed lifetime and per-visitor limits, not stored indefinitely.
  • Submitted inquiries are written server-side on infrastructure we control, then delivered to our team.
  • The AI-suggested price bracket is internal. A person sets every number a client is shown.

Administrative access

  • Passwords are stored as PBKDF2-HMAC-SHA256 hashes and compared in constant time. No password is stored in a recoverable form.
  • Sessions use a signed, HTTP-only, SameSite=Strict cookie with a fixed expiry.
  • Every state-changing request carries a CSRF token.
  • Login attempts are rate limited per address, and lock out after repeated failures.
  • Administrative actions are written to an audit log.
  • Administrative pages are excluded from search indexing and served with no-store cache headers.
  • The admin panel controls runtime settings only. It cannot edit published content.

Abuse resistance

  • Public endpoints are rate limited per address using a token bucket.
  • Unknown paths return a real 404 rather than a soft error page.
  • Uploaded and submitted values are validated and clamped before they reach storage.

Secrets and source control

  • Credentials and API keys live in environment variables, never in the repository.
  • Runtime data directories are excluded from version control.
  • Every change is scanned for accidentally committed secrets before it is pushed.

Release process

  • An automated quality gate runs on every build: content validation, canonical and sitemap checks, a bundle size budget, and a lint pass.
  • Backend and frontend test suites run before release, alongside a replay of every legacy URL to confirm redirects still resolve.

Reporting a vulnerability

If you believe you have found a security issue, email [email protected] with enough detail to reproduce it. Please give us a reasonable opportunity to investigate and fix the issue before disclosing it publicly. We are grateful for reports made in good faith and will not pursue action against researchers who act responsibly and avoid privacy violations or service disruption.

Honest limitations

No system is completely secure, and this page claims no certification, audit, or third-party assessment, because we hold none. What is written above is what is implemented. Client engagements can carry stricter, contractually defined security requirements, and those are set out in the relevant agreement rather than here.