Security.

01 · The surface

What is exposed, and what is not

The public API surface is read-only views behind a publishable key. The key printed in every receipt is meant to be public, and finding it is not a finding.

The public surface is the api schema and nothing else. PostgREST exposes no other schema, and the record's tables are readable only through those views. Row-level security is enabled throughout, and it is a floor rather than the boundary: the boundary is which schema is published.

The record's write paths answer only to service credentials, and the operational schemas answer to no public request at all. The one public write door is the interest form: validated, length-capped and deduplicated; rate limiting lands with the accounts work. It is firewalled from the record it can never touch.

The record makes tampering visible rather than merely forbidden: rows cannot be hard-deleted, every change is captured in a revision ledger, and every row's content hash can be replayed against its source.

02 · Dependencies

Known exceptions

One advisory appears on every dependency scan of this site and it is unreachable here. GHSA-pxg6-pf52-xh8x, the cookie package at 0.6.0, arrives as a dependency of the framework itself. It concerns how a cookie is constructed. This site sets no cookie on any route, so no code path constructs one, and the version is held by the framework's own dependency range rather than by a choice made here. That is checkable from outside: no response from this origin carries a Set-Cookie header, which is one of the four checks published on the cookies page.

It is listed here rather than left in a scan report, because a finding that is answered before it is raised is worth more than a silence a buyer has to interpret. The day the framework moves its range, this line goes and the dated revision says so.

03 · Reporting

Reporting a weakness

Found a way to write where writing is sealed, or to read what is not published? info@heimlandr.com. Describe what you found and how to reproduce it. You will get a human answer.

Please do not run volume attacks against the public door to prove a point about volume, and do not touch data belonging to anyone who filed the interest form.

There is no bounty program at pre-launch. Reports are credited, with thanks, unless you prefer otherwise.

04 · Disclosure

How disclosure runs

We fix first, then publish. A confirmed weakness and its repair are disclosed on this page by dated revision, in the same register as everything else in the house. A security failure is a correction, and corrections here are public. Give us reasonable time to fix before you publish independently, and we will not make you regret the courtesy.