Security & Threat Model

This document describes the security architecture of trentpower.fr: what it protects, what it considers a threat, and how risk is managed.

It focuses on system posture and operational controls. Verification of published content is described separately under Integrity.

1. Architecture Architecture diagram: visitor request flows through DNS with DNSSEC, TLS, Varnish cache, and Apache with security headers to public static files. Deployment flows from local authoring through SFTP to Apache, producing a PGP-signed integrity manifest.

The public site is static HTML, CSS, and vanilla JavaScript.

There is:

  • No runtime server logic
  • No public database
  • No public forms
  • No third-party scripts, embeds, or trackers

It is hosted on Apache and deployed manually via SFTP.

2. Assets protected

The controls described here protect:

  • Domain ownership
  • DNS integrity
  • Hosting account integrity
  • Public content integrity
  • The signing key used for release authenticity
3. Threat model

Infrastructure compromise

  • Registrar account takeover
  • DNS hijack
  • Hosting credential compromise

Content tampering

  • Post-deployment file modification
  • Malicious JavaScript injection
  • Silent alteration of static assets

Administrative abuse

  • Credential stuffing
  • Automated vulnerability scanning

Commodity internet noise

Continuous automated probing for common CMS paths, configuration files, or known endpoints. These are treated as persistent background conditions rather than exceptional events.

4. Controls

Registrar & DNS

  • Multi-factor authentication enabled
  • Registrar lock active
  • DNSSEC enabled and validated
  • CAA records restrict certificate issuance

Hosting

  • Multi-factor authentication enabled
  • SFTP-only deployment
  • No SSH shell exposure
  • No scheduled background execution

Public content

  • Static architecture reduces server-side attack surface
  • Strict Content Security Policy starting from default-src 'none'
  • No external resource loading
  • No dynamic script execution

Monitoring

  • Structured log analysis
  • Pattern detection and anomaly scoring
  • File integrity drift detection against the signed release baseline
5. Release & verification

This site follows a finite release model. Each deployment is discrete and signed.

Technical verification details, including integrity manifests and cryptographic signatures, are documented in the Integrity section.

6. Residual risk

This model does not attempt to address:

  • Physical compromise of hosting infrastructure
  • Global DNS root compromise
  • Certificate authority compromise
  • State-level adversaries
  • Zero-day browser exploits on client devices

These are acknowledged residual risks for a personal static publication platform.

7. Disclosure

Responsible disclosure is welcome. Security contact details and encrypted communication instructions are published at /.well-known/security.txt.

8. Design principles
  • Simplicity over complexity
  • Deterministic behaviour over dynamic systems
  • Transparency over obscurity
  • Verifiable integrity over trust assumptions
← Privacy & Trust