SC-23 Session Authenticity has one requirement: protect the authenticity of communications sessions. Behind that short line is most of what people mean by secure web sessions, login cookies and tokens.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from, so check which parts your customer or auditor actually expects.
The guidance says this is protection at the session level and not at the packet level. It builds confidence at both ends in the ongoing identities of the other parties and the validity of what is transmitted. It covers protection against man in the middle attacks, session hijacking and the insertion of false information into sessions.
What it means in practice
After a user logs in, your system hands out something that stands for that login: a cookie, a token, a session identifier. Anyone who steals or guesses it can act as the user. SC-23 asks you to make sure that does not happen, and that both parties can keep trusting who is on the other end.
Five enhancements name the common practices:
- SC-23.1, Invalidate Session Identifiers at Logout. When a user logs out, the server discards the session, so a copied identifier no longer works.
- SC-23.2, User-initiated Logouts and Message Displays. Offer a logout control and show a clear message when it has completed.
- SC-23.3, Unique System-generated Session Identifiers. The server creates identifiers and never accepts ones chosen by the client.
- SC-23.4, Unique Session Identifiers with Randomization. Identifiers come from a strong random source so they cannot be predicted.
- SC-23.5, Allowed Certificate Authorities. Sessions only trust certificates from authorities you allow.
Transport security is the baseline. Use TLS everywhere, and set cookies with secure and HTTP only flags and a sensible same site policy. Add short idle and absolute timeouts, and rotate the identifier at login and when privileges change.
Evidence to collect
- Configuration showing TLS is enforced, with HSTS where it applies.
- Cookie attributes from a live response: secure, HTTP only, same site.
- A test showing the old session identifier is rejected after logout.
- Framework or library documentation showing identifiers come from a cryptographically strong generator.
- Session timeout settings for idle and absolute lifetimes.
- Login flow test showing the identifier changes after authentication.
- For service to service sessions, the certificate or token validation configuration, including allowed certificate authorities.
- Results of a recent web application test covering session management.
Common gaps
Session tokens that survive logout because logout only deletes the cookie in the browser. Tokens that never expire. Identifiers placed in URLs, where they leak through logs and referrer headers. Custom home grown session code with weak randomness. Login that does not rotate the identifier, enabling session fixation. Mobile apps that skip certificate validation in test builds that reach production. Internal services that accept any certificate.
APIs bring their own version of these gaps: long lived bearer tokens that cannot be revoked, and refresh tokens with no rotation.
How to implement it
Use your framework's session handling instead of writing your own. Check its defaults against the list above. Turn on TLS everywhere, add HSTS, and set cookie flags.
Make logout real. Delete the server side session record, or add the token to a revocation list that is checked on each request. Test it by replaying a captured identifier after logout.
Pick timeouts to match risk. Administrative sessions deserve shorter lifetimes and re authentication for sensitive actions.
Rotate identifiers at login and privilege change. For tokens, prefer short lifetimes with controlled refresh.
For certificate validation, pin the set of allowed authorities for sensitive connections, and fail closed. Check that debug flags that disable validation cannot be enabled in production.
Finally, test. A recurring application security test or a scripted check in your pipeline catches regressions. Keep the outputs as dated evidence.
If you build tokens into your own API, document the lifetime, revocation path and storage in one page. That page often answers half of an auditor's questions before they are asked.
Here is the sort of test an assessor will ask you to run. Log in, copy the session cookie with the browser developer tools, log out, then replay the copied cookie in a separate request. If the server answers with the logged in page, the session survived logout and SC-23.1 is not met. Run the same replay after the idle timeout expires and after a password change. Each should fail. Save the requests and responses with dates. A short script that performs these checks in your pipeline gives you recurring evidence for free.
Another simple check looks at the login response. The identifier before login and after login should differ. If it does not, an attacker who plants a known identifier on a victim before login can reuse it afterward, which is session fixation.
For machine to machine sessions, similar thinking applies. Short lived tokens, mutual TLS between services and a clear list of certificate authorities each reduce the chance that a stolen credential works for long or from anywhere.
Finally, document the exceptions. Some kiosks and wall displays need very long sessions. If you allow them, list them, limit what they can reach and monitor them closely. A documented exception is a much better answer than an undocumented one.
Quick check
Is deleting the cookie in the browser enough at logout?
No. The server must invalidate the session so a copied identifier stops working. That is what SC-23.1 describes.
Why randomize session identifiers?
So attackers cannot predict valid ones. SC-23.4 asks for unique identifiers with randomization.
