Security
Exposed Files Panels: what to verify before client handoff
Before client handoff, verify that env files, backups, and admin consoles are not publicly reachable on the URLs you are actually shipping—and keep secrets and default-credential siblings on separate tickets.
· by Sam Ortega

Handoff calls go sideways when a client pastes https://their-site/.env into chat and gets a download. Screenshots of the homepage do not catch that. Uptime green does not catch that either.
SlaySlop defines Exposed files and admin panels as a check that "Checks for publicly reachable env files, backups, and admin consoles." That is the bar I put in the handoff packet next to the Security category—not a vibe that "we locked production."
Outcome you want at handoff
In-scope hosts should not publicly serve env files or backup archives, and admin consoles should match whatever reachability policy you promised (often: not world-open on production, or at least documented and credential-hardened). Findings attach to paths. Client-side secrets and Default credentials stay separate rows so nobody claims "security done" after one fix.
I have watched a launch-week portal look perfect while a leftover site-backup.zip still sat on the same CDN hostname the ads pointed at. Process that survives launch week treats path reachability as a checklist item with an owner, not a hallway assumption.
Boundaries to say out loud
Permissioned, read-only scan. Not a pentest. SlaySlop will not chmod the file for you. You need access to the host, object storage, or CDN config to fix reachability. A clean Exposed files and admin panels result is not a Client-side secrets pass and not a Default credentials pass.
Keep the sibling definitions handy if the client asks what was measured:
- Client-side secrets: searches public bundles and responses for exposed keys and tokens
- Default credentials: unchanged vendor default logins on detected stacks when ownership is verified
- Known CVEs: known CVE templates after ownership is verified
Loading diagram.
Happy path checklist
- List production and any staging hosts named in the SOW.
- Run or review Exposed files and admin panels findings on those hosts.
- For each open path: confirm with a permissioned HEAD/GET what status and content-type the public surface returns.
- Remove or block the file/console exposure at origin or edge. If an env or backup was downloadable, rotate anything that might have been inside—do not debate whether "anyone saw it."
- Check Default credentials if an admin console remains intentionally public.
- Check Client-side secrets for keys in bundles.
- Rescan the same hosts. Put the cleared finding IDs in the portal.
# Boring handoff host list
cat <<'HOSTS'
https://www.client.example/
https://staging.client.example/
HOSTS
# Spot-check a path cited in evidence (permissioned)
curl -sI "https://www.client.example/.env" | sed -n '1,12p'handoff_note:
check: Exposed files and admin panels
hosts: www + staging
open_paths: none after rescan
rotations: env keys rotated YYYY-MM-DD (vault ref only)
siblings: client-secrets=clear|open; default-credentials=clear|openWhat embarrasses you on a call is discovering backup.sql.gz still on the marketing CDN while you narrate "we take security seriously."
Pitfalls that show up after you send the portal
Fixing only production and forgetting the preview host linked from the client's Notion. Relying on robots.txt Disallow. Renaming /wp-admin and declaring panels solved while /.env still serves. Closing the ticket because Monitoring shows uptime—availability is not this check.—availability is not this check. Dumping rotated secrets into the handoff PDF "so the client has them"—use their password manager.
If the agency retains admin access for a warranty window, write that down. Reachability policy and credential custody are easy to confuse on a hurried call.
Related next step
Share the read-only portal with the path evidence visible. Soft link the glossary if the client asks what was measured. Keep Monitoring on so a reintroduced backup after a migration shows up again. Reports and portals exist so the client sees the same evidence without a live share-screen scramble.
What I put in the portal vs the internal ticket
The portal gets the glossary definition, the host list, and whether paths remain open after rescan. The internal ticket gets rotation vault references (not secret values), the CDN purge ID if you have one, and the name of the person who owns Default credentials if a console stays public on purpose.
Agencies lose an hour on the handoff call when those two documents disagree. I make the portal the boring subset of the ticket, not a second creative writing exercise.
If Reports and portals is how the client receives evidence, walk them through one cleared path so they see what "reachable" meant. That is usually enough. Soft product mention only because the portal is the artifact you are handing over.