Security is a product requirement across identity, permissions, connected actions, and public site delivery.
1 min read
Public website / Engineering scope
Inspect the control. Inspect its evidence.
Implementation, configuration, deployment, and verification are separate stages. The evidence below describes candidate engineering checks; it does not assert an independent audit or protection of a separate Merism service.
Content Security Policy
Implementation
Server-generated per-response nonce; no inline event handlers; restricted resource origins.
Verification method
Production build and response tests check nonce freshness, script coverage, and rejection of caller-supplied policies.
Deployment and limits
Requires verification on the exact deployed version.
Browser defenses
Implementation
Content-type, framing, referrer, and permissions protections are implemented in the delivery configuration.
Verification method
Local production response and asset checks inspect the configured headers.
Deployment and limits
Account-level edge overrides and canonical responses require live checks.
Public content boundary
Implementation
Only explicitly PUBLIC records enter routing, search, indexes, relationships, and the sitemap.
Verification method
Projection tests exercise draft, review, archived, and unclassified records.
Deployment and limits
Public records still require editorial and factual review.
Input and abuse controls
Implementation
Optional intake validates origin, content type, bounded bodies, fields, challenge results, and rate limits before storage.
Verification method
Synthetic tests cover rejection, outages, replay, and closed intake.
Deployment and limits
Public collection remains closed; source tests do not establish an operational support service.
Secrets and observability
Implementation
Public artifact checks reject private identifiers and destinations. Optional error telemetry requires verified configuration and excludes protected content.
Verification method
Build scans and telemetry tests check the configured boundary.
Deployment and limits
No certification or guarantee that all possible secrets are detected.
Registrar, edge, and incident operations
Implementation
Registrar MFA, domain lock, full DNS export, edge rules, origin isolation, and monitored reporting are separate operational controls.
Verification method
Public DNS and TLS observations cannot verify authenticated account settings.
Deployment and limits
Account evidence and incident ownership remain under review.
Independent assessment: no certification, compliance authorization, or third-party audit is claimed here.
Account and tool boundaries
Merism is designed to require appropriate identity, authorization, and bounded tool permissions. These design goals do not state that every control is deployed.
Public site
The company site is separate from the authenticated Merism application. Security headers, edge rules, origin isolation, and incident processes require exact deployment evidence.
Reporting
Good-faith reports should use a verified official channel once published. We will not ask for passwords, recovery codes, or API keys by email.
