Security

Ensan ID is designed as privacy-preserving identity infrastructure. Security is part of the product boundary, not an optional feature.

Architecture

The public web root contains only the public shell, public assets, and route entry points. Private content and private logic are stored above the web root.

Private content contains text and structured public-facing copy. Private logic contains controllers, services, repositories, validators, security utilities, database access, OAuth clients, and verification logic.

Core controls

• Private folders above `public_html`.
• Production config stored outside public access.
• Prepared SQL statements.
• Input validation.
• Output escaping.
• CSRF protection for state-changing actions.
• Hardened sessions.
• Security headers.
• Rate limiting.
• Audit logging.
• OAuth state validation.
• No long-lived OAuth token storage by default.
• Hashed holder management tokens.
• Binding revocation and dispute handling.

Holder security

The `.ensan` capsule should be treated as sensitive private identity material. Protect it with a strong passphrase and secure storage.

The management token is displayed once and stored only as a hash server-side. Store it securely. Losing it may prevent normal holder management.

OAuth security

GitHub and ORCID bindings should use the minimum required access. Provider callbacks must validate state and reject unrecognized flows. OAuth configuration belongs in private config, not public files.

DNS and reciprocal-link security

DNS TXT and reciprocal-link checks prove that a public challenge was visible at check time. They do not prove permanent future control. Binding expiry and rechecks reduce stale trust.

Operator security

Delete `public_html/install.php` after installation. Keep installer locks. Use HTTPS. Back up database and private config files. Restrict database privileges. Monitor audit logs. Review disputes promptly.

Reporting

Report suspected vulnerabilities, impersonation, or abuse to ipcontrol@knowdyn.co.uk.