A supported dotenv path returned dotenv-like assignments
A supported dotenv path returned non-HTML content containing multiple dotenv-style variable assignments.
Why it matters
A publicly served configuration artifact deserves review because its assignments may reveal deployment settings. ShipReady does not classify or validate the values it deliberately avoids reporting.
How ShipReady detects it
What it inspects
ShipReady probes only /.env, /.env.local, /.env.production, /.env.production.local, and /.env.development on the scanned origin.
A probe must return HTTP 200, not resemble an SPA fallback or HTML response, and contain at least two distinct uppercase dotenv-style assignment names.
What triggers a finding
The rule triggers for each supported path meeting those response and assignment-shape conditions.
What the evidence shows
The reported supported path returned non-HTML content with multiple dotenv-style assignment names. Variable values are never retained in the finding evidence.
Limits of this check
ShipReady does not prove the response is a canonical .env file, classify values as secrets, validate their use, or establish compromise. It does not follow redirects; non-200, fallback-like, HTML, unanswered, or edge-blocked probes do not create a finding.
How to fix it
Review the exact public artifact
Confirm why the reported path is served and whether its assignments belong in public output.
Publish only intended output
Remove unintended configuration artifacts from deployed static output and adjust server, CDN, and deployment rules so the path is not publicly served.
How to verify the change
Request the reported path after deployment
Fetch the exact reported path without credentials and inspect the response.
Expected: The path no longer returns the unintended dotenv-like configuration content.