fix: clarify TLS policy — services never terminate TLS directly
All checks were successful
check / check (push) Successful in 5s
All checks were successful
check / check (push) Successful in 5s
Our services always sit behind a TLS-terminating reverse proxy and listen on plain HTTP. Updated the TLS subsection to state this as policy rather than presenting it as one of two options.
This commit is contained in:
@@ -179,9 +179,10 @@ style conventions are in separate documents:
|
|||||||
or other implementation details to the client. Return generic error
|
or other implementation details to the client. Return generic error
|
||||||
messages in production; detailed errors only when `DEBUG` is enabled.
|
messages in production; detailed errors only when `DEBUG` is enabled.
|
||||||
- **TLS:**
|
- **TLS:**
|
||||||
- The service itself may terminate TLS or sit behind a TLS-terminating
|
- Services never terminate TLS directly. They are always deployed behind
|
||||||
reverse proxy, but HSTS headers and secure cookie flags must be set
|
a TLS-terminating reverse proxy. The service itself listens on plain
|
||||||
regardless so that the browser enforces HTTPS.
|
HTTP. However, HSTS headers and `Secure` cookie flags must still be
|
||||||
|
set by the application so that the browser enforces HTTPS end-to-end.
|
||||||
|
|
||||||
This list is non-exhaustive. Apply defense-in-depth: if a standard security
|
This list is non-exhaustive. Apply defense-in-depth: if a standard security
|
||||||
hardening measure exists for HTTP services and is not listed here, it is
|
hardening measure exists for HTTP services and is not listed here, it is
|
||||||
|
|||||||
Reference in New Issue
Block a user