Add global X-Content-Type-Options: nosniff where feasible

[SueValente]

User Story

In order to improve baseline web security hygiene and reduce recurring low-severity scan findings, the Data.gov team wants retained web applications to return X-Content-Type-Options: nosniff where appropriate.

Acceptance Criteria

• GIVEN an in-scope retained Data.gov web endpoint returns HTTP responses for browser-consumed content
  WHEN response headers are inspected in the deployed environment
  THEN X-Content-Type-Options: nosniff is present where appropriate

• GIVEN a shared proxy, middleware, or application base configuration can apply this header consistently
  WHEN implementation is completed
  THEN the header is added centrally rather than by one-off page fixes where feasible

• GIVEN any route or service cannot safely return this header
  WHEN the implementation decision is documented
  THEN the exception and rationale are added to this ticket

• GIVEN remediation has been deployed
  WHEN verification is completed
  THEN evidence is added to this ticket

Background

This ticket is part of a broader effort to clean up recurring low/medium web security findings across Data.gov systems by focusing on fixes that can be applied centrally and that reduce recurring scan noise.

This specific ticket is intended to address repeated Missing X-Content-Type-Options Header findings across multiple environments and applications. Because this issue appears repeatedly, the preferred approach is to add the header through shared configuration where possible.

Examples from recent scan results include:

• https://inventory.data.gov/ (Production)
• https://catalog-prod-admin-datagov.app.cloud.gov/ (Production)
• https://catalog-dev-admin-datagov.app.cloud.gov/ (Development)
• https://ssb-solrcloud-gsa-datagov-management.app.cloud.gov/ (Production)
• https://ssb-solrcloud-gsa-datagov-development-ssb.app.cloud.gov/ (Development)
• https://inventory-stage-datagov.app.cloud.gov/ (Staging)
• https://inventory-dev-datagov.app.cloud.gov/ (Development)

Reminder to future us:

• The purpose of this work is to clear a repeated class of low-severity findings efficiently through central hardening, not to hand-edit every individual route.
• If some platforms are being deprecated, apply this only to systems being retained.
• When completed, notify Nina (ISSO) so the recurring findings can be reviewed for validation/closure.

Security Considerations (required)

Adding X-Content-Type-Options: nosniff helps reduce MIME-type sniffing behavior in browsers and is generally a low-risk hardening change. Security considerations include:

• validating that adding the header does not interfere with legitimate content delivery patterns
• preferring shared configuration to reduce drift across environments
• ensuring deprecated systems are not driving unnecessary remediation effort

Sketch

• Identify retained systems where this finding recurs
• Determine whether the header can be set in:
  • shared proxy config
  • middleware
  • base application config
• Implement centrally where feasible
• Validate on representative endpoints
• Record any exceptions

Assign to Sue when Done

• Notify Nina when ready for validation/rescan