Express.js / Editorial solution guide
Diagnose secure cookies, proxy trust and browser rejection
Separate transport reconstruction, cookie eligibility, session authority and CORS before relaxing access policy.
Read-only knowledge base · No public comments
Recognize the symptoms
Login works locally but not behind an ingress, a secure cookie is not retained, every client appears to have the proxy address, or browser script cannot read an authenticated response. A successful HTTP connection does not prove the browser stored credentials or that the server accepted a valid session.
Understand the likely causes
- Likely causes include a trust proxy mismatch, unrewritten forwarded headers, cookie domain/path/SameSite/Secure mismatch, missing credential mode, incompatible CORS headers, expired server authority or an unsuitable session store. These layers need separate evidence; broad trust and wildcard origin settings can introduce new vulnerabilities without fixing the actual fault.
Confirm the intended ingress and trustworthy metadata
Use approved deployment records to identify TLS termination, trusted proxy addresses, header rewriting and every path to the app. Compare the intended original protocol and client address with safe existing request metadata. Do not trust arbitrary X-Forwarded-* values or assume a numeric hop count is safe under a shorter alternate path. A private internal HTTP hop can coexist with a public HTTPS connection, but only a verified proxy policy should reconstruct that fact. Never disable secure cookies merely because the app sees the internal hop as HTTP.
Trace cookie eligibility and server authority separately
Inspect safe cookie attributes and browser reasons for rejection without copying identifier values into logs. Domain, path, Secure, SameSite and expiry must fit the actual origin/site workflow. HttpOnly limits script reads, so absence from document.cookie is not proof the browser lacks the cookie. Confirm whether the browser sent it on the intended request, then whether the session store accepted current authority. Logout and expiry need server-side invalidation policy. A process-local default MemoryStore is not an adequate shared production session design across workers, and sticky routing does not turn it into durable state.
Diagnose browser-read policy without confusing it with login
For cross-origin browser access, compare Origin, requested method/headers, preflight, actual response and the client’s credential mode. A credentialed response needs a compatible explicit approved origin, not a wildcard shortcut. CORS headers govern browser response reading and do not prevent arbitrary clients or forged state changes. Keep authentication, object policy and CSRF intact. The JSON below is a synthetic review checklist, not a tested live configuration. Treat missing or null origins according to documented client needs rather than approving them to remove a visible error.
{"review":["verified-ingress","forwarded-header-rewrite","cookie-eligibility","current-session-authority","approved-origin","credential-mode","csrf-policy"],"secretValues":"excluded","execution":"no-live-browser-or-proxy-test"}The checklist names independent evidence. It sends no request and configures no cookie, proxy or CORS middleware.
Repair the failed layer and retest the complete path
Correct the approved ingress trust or header rewriting when topology is wrong. Repair cookie scope and lifecycle when browser eligibility fails; repair store identity or revocation when server authority fails. Update only the approved origin/credential policy for a genuine CORS mismatch. Then verify login, permitted read, denied object, logout, expiry and an identity switch through the same intended path. This editorial guide performs no proxy, browser or session operation. Real verification needs an authorized isolated deployment and synthetic identities, with no real credential values stored in the evidence.
Verify the fix
The repaired path should preserve TLS interpretation, approved cookie attributes, current session authority and exact object denial. Verify allowed and denied origins and logout/expiry independently. Confirm that a late response from the previous principal cannot populate the next principal’s client cache.
Keep it from recurring
- Document proxy topology and session-store ownership with pinned versions. Keep cookies and tokens out of logs, review cache audience and retain browser/proxy fixtures. Avoid universal trust proxy, wildcard origin or disable-CSRF remedies that erase distinctions needed for a correct diagnosis.