Skip to content

Pre-public hardening: secure cookies in production, widen .gitignore#3

Merged
mjdavidson merged 1 commit into
mainfrom
pre-public-hardening
Jul 16, 2026
Merged

Pre-public hardening: secure cookies in production, widen .gitignore#3
mjdavidson merged 1 commit into
mainfrom
pre-public-hardening

Conversation

@mjdavidson

@mjdavidson mjdavidson commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

The two "recommended" findings from the pre-public audit:

Session cookie secure flag — previously a comment told readers to enable cookie.secure and trust proxy once serving HTTPS. Since example code gets copied verbatim and that comment is easy to miss, the code now does it: secure: NODE_ENV === 'production' plus app.set('trust proxy', 1) in production. Dev behavior over plain HTTP is unchanged.

.gitignore widening — only the literal .env was ignored, so a clone using .env.local or .env.production (both conventional) could silently commit real keys. Now .env* is ignored with a !.env.example negation.

Verified: lint / format / typecheck green; app booted and served in both dev and NODE_ENV=production; git check-ignore confirms .env, .env.local, .env.production ignored and .env.example not.


Devin shepherd: https://app.devin.ai/sessions/5cea8ddb44784c8596bedfa2670129a7

- Session cookie gets secure: true (with trust proxy) under
  NODE_ENV=production instead of relying on a comment telling the
  reader to flip it
- Ignore all .env* variants except .env.example so adapted clones
  can't accidentally commit .env.local / .env.production

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

Open in Devin Review

@greptile-apps

greptile-apps Bot commented Jul 16, 2026

Copy link
Copy Markdown

Greptile Summary

This PR hardens session cookie handling and environment-file ignores. The main changes are:

  • Production runs now set trust proxy to support TLS-terminating proxies.
  • Session cookies now use secure: true when NODE_ENV=production.
  • .gitignore now ignores .env* files while keeping .env.example trackable.

Confidence Score: 5/5

This PR is safe to merge with minimal risk.

The changes are small, targeted hardening updates that match the stated intent and do not introduce correctness or security regressions in the reviewed paths.

No files require special attention.

T-Rex T-Rex Logs

What T-Rex did

  • Validated production and development server behavior under proxy trust settings, confirming HTTPS forwarding in production and plain HTTP in development with corresponding 200 responses and cookie headers.
  • Verified .gitignore behavior for environment files, confirming env* files are ignored while .env.example is not ignored.
  • Confirmed lint and typecheck results, with both lint and typecheck exiting zero, and noted the format check reported artifacts generated for internal validation rather than PR source files.
  • Organized and linked the relevant artifacts to support the contract-validation findings for reviewer access.

View all artifacts

T-Rex Ran code and verified through T-Rex

Important Files Changed

Filename Overview
.gitignore Expands environment file ignore patterns while preserving .env.example; no issues found.
src/app.ts Enables production-only secure session cookies and proxy trust for TLS-terminating deployments; no issues found.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Browser
participant Proxy as TLS-terminating proxy
participant App as Express app
participant Session as express-session

Browser->>Proxy: HTTPS request
Proxy->>App: Forwarded request with original protocol
App->>App: "NODE_ENV == production sets trust proxy = 1"
App->>Session: "Configure cookie.secure = true"
Session-->>Browser: Set-Cookie only when request is HTTPS
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant Browser
participant Proxy as TLS-terminating proxy
participant App as Express app
participant Session as express-session

Browser->>Proxy: HTTPS request
Proxy->>App: Forwarded request with original protocol
App->>App: "NODE_ENV == production sets trust proxy = 1"
App->>Session: "Configure cookie.secure = true"
Session-->>Browser: Set-Cookie only when request is HTTPS
Loading

Reviews (1): Last reviewed commit: "Pre-public hardening: secure cookies in ..." | Re-trigger Greptile

@devin-ai-integration

Copy link
Copy Markdown

Thanks @greptile-apps — 5/5, no changes needed. One clarification for future readers: the cookie is set with secure: isProduction (i.e. secure: true only when NODE_ENV=production), deliberately not unconditional true, since this demo is served over plain HTTP in dev and unconditional secure would silently drop local sessions. trust proxy is likewise gated to production. Both are intentional and scoped to the two audit findings.

@greptile-apps

greptile-apps Bot commented Jul 16, 2026

Copy link
Copy Markdown

Noted, thanks for the clarification. The conditional behavior is exactly right for a demo that runs over plain HTTP locally — unconditional secure: true would cause browsers to silently discard the session cookie on HTTP, breaking the dev flow entirely. The production gate on trust proxy is similarly correct since trusting the proxy unconditionally in a local context could allow a malicious X-Forwarded-Proto header to spoof the HTTPS scheme. Both choices are sound.

@mjdavidson
mjdavidson merged commit 7485aba into main Jul 16, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant