Security posture and principles

Five principles run through every design decision in PEART. They are worth stating on their own, because the rest of this section is their application.

Secure by default, refused when unsafe

PEART refuses unsafe configuration rather than falling back to a convenient default. The shipped config.example.yaml does not run as-is: the rendering token is a placeholder the configuration validator rejects outright, with no default it could silently substitute. Running without TLS refuses to start unless the operator also sets accept_insecure_http, so a plain-HTTP deployment is always an explicit choice, never an accident. Placing the master key inside a data directory is refused at boot, because that would put the key in the same backup as the data it protects. A dangerous setup has to be asked for; it is never the path of least resistance.

Least privilege

Each process holds only what it needs. The portal reads everything the client sees through a connection the SQLite driver itself refuses a write on, and keeps a second, narrow connection for the only rows it writes about itself: its session, its audit entries, the password set from an invitation and the optional second factor. Neither one carries the master key or reaches the evidence directory. The PDF renderer runs with no network, no database, no key and no evidence access, receiving only a working directory of already-resolved HTML and returning a PDF. A compromise of one surface does not hand over the assets the other surfaces hold.

Defense in depth

No single control is trusted to be sufficient. Hostile content is contained by process separation, a strict Content-Security-Policy, per-context output escaping, and a restricted Markdown dialect, layered so that a gap in one is not a breach on its own. The PDF renderer alone stands behind three independent layers, none of which is relied on by itself.

Hostile content by default

Every text field is treated as hostile input, including the ones filled in by trusted users. A pentester recording an XSS or SQL-injection payload as finding text is doing exactly the job, and the effect of that content is indistinguishable from an attacker's. PEART stores, displays, exports and prints those strings without ever executing them, across every output context.

Declared limitation over vague promise, relate over certify

PEART states plainly what it does not protect, because a security product that overstates its guarantees loses the ones it has. And its compliance mapping relates a finding to a control, it never certifies compliance. Both are the same instinct: say exactly what is true, and let the reader trust it because it is not inflated.