Application exposure
Exposed files and source maps in production
Find and remove public environment files, Git metadata, backups, debug pages, and JavaScript source maps from a SaaS deployment.
A deployment can work perfectly while publishing files that were never meant for a browser. Environment files, repository metadata, database backups, logs, and source maps often appear because the build artifact is too broad or the web root points at the wrong directory.
The first response is containment. The second is fixing the pipeline that allowed the file to ship.
Treat confirmed secrets as compromised
If a public file contains credentials, removing the file is not enough. Rotate the exposed values, review access logs, and identify what each credential could reach. A secret may have been copied before your scan found it.
- Remove public access or take the affected deployment offline.
- Rotate API keys, database passwords, signing secrets, and tokens found in the file.
- Review provider and application logs for unexpected use.
- Document the incident and any required user or regulator notification.
Publish a build artifact, not the repository
The safest deployment copies only the files needed at runtime. Do not sync the entire working directory to a web root. Keep .git, local environment files, test fixtures, SQL exports, and editor artifacts outside the published output.
- Use a clean build directory created in CI.
- Inspect the artifact before upload and fail the build on forbidden patterns.
- Configure the server to deny dotfiles and backup extensions as a second layer.
- Keep backups in private object storage, never beside public application assets.
Handle source maps deliberately
Browser source maps can reveal readable source, file paths, comments, and internal names. That does not automatically create an exploit, but it gives an attacker a much clearer map of the client application.
If an error-monitoring service needs source maps, generate them in CI, upload them privately, and exclude them from the public artifact. Also remove sourceMappingURL references when your build tool leaves them behind.
Verify the fix from outside
Test the exact production URLs after redeploying. A CDN may cache the old file even after it disappears from the origin. Purge the relevant paths, confirm they return a real 404 or access denial, and run a fresh scan against the public hostname.
Check your production site
See which of these issues are visible now.
ScanMySaaS checks the public surface and keeps the affected URL with every finding. Verify results before changing production.
Run a free scan