Production/admin CORS review and hardening

[SueValente]

User Story

In order to reduce cross-origin exposure risk and address recurring scan findings, the Data.gov team wants production and production-admin endpoints to use intentionally scoped CORS behavior.

Acceptance Criteria

• GIVEN an in-scope production or production-admin endpoint returns CORS headers
  WHEN the endpoint configuration is reviewed
  THEN the allowed origin behavior is documented as required, intentionally public, or needing restriction

• GIVEN an endpoint supports credentialed browser requests
  WHEN its CORS policy is reviewed
  THEN it does not use an unsafe wildcard origin configuration for credentialed access

• GIVEN an endpoint does not require cross-origin browser access
  WHEN its response headers are reviewed
  THEN unnecessary CORS headers are removed or restricted

• GIVEN remediation decisions are complete
  WHEN this ticket is updated
  THEN each in-scope endpoint is marked as fixed, accepted with rationale, or moved to a linked follow-on issue

• GIVEN remediation has been deployed for any changed endpoints
  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 high-value fixes and reducing repeated scan noise through shared hardening.

This ticket is intended to address recurring Misconfigured Access-Control-Allow-Origin Header findings, especially on production and admin surfaces where browser-based cross-origin behavior may matter more.

Examples from the monthly scan that should be reviewed first:

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

Related non-production endpoints may be reviewed separately, especially if a shared configuration pattern is discovered.

Reminder to future us:

• The point of this ticket is to determine whether these are real cross-origin exposure issues, shared config defaults, or acceptable behavior on public endpoints.
• Do not assume every scanner-reported CORS issue is equally risky.
• When remediation/analysis is complete, notify Nina (ISSO) so findings can be revalidated or documented appropriately.

Security Considerations (required)

CORS behavior can affect whether browser-based applications from other origins can read responses or make credentialed requests. Security considerations include:

• preventing overly broad cross-origin access on authenticated or administrative endpoints
• ensuring wildcard origins are not used unsafely with credentials
• preserving legitimate public API behavior where intentionally designed
• documenting accepted configurations where the scanner result is low risk or expected

Sketch

• Inventory current CORS headers for each in-scope endpoint
• Determine whether each endpoint:
  • is public or administrative
  • uses cookies or other browser credentials
  • truly requires cross-origin access
• Classify each result as:
  • valid and intentionally public
  • needs restriction
  • scanner noise / low-risk accepted configuration
• Tighten configuration where needed
• Capture endpoint-by-endpoint decisions in the ticket

Assign to Sue when Done

• Notify Nina when ready for validation/rescan