AutoCore Proxy Exposure and Verification
A security checklist for edge routing, forwarding headers, TLS, health, and Admin exposure.
Verify the deployed edge from outside the host and verify application behavior from inside the trusted proxy boundary. Example domains in this article are non-routable documentation placeholders.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Host routing | Each intended host reaches only its intended application surface. |
| Headers | Client IP and protocol headers are trusted only across the configured proxy boundary. |
| Health | Health endpoints expose safe status, not credentials, datastore URLs, or provider payloads. |
| Admin | Admin is separately routed, authenticated, noindex, and not treated as a secret URL. |
| TLS evidence | Capture certificate, protocol, redirect, HSTS, and renewal evidence without publishing private host data. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.