Security & Infrastructure · 2026-07-05
Air-Tight Demo Security: Sandboxing Destructive Actions in the Danger Zone
Why I built a dedicated sudo-guarded console for dangerous operations — and fixed an output-encoding bug along the way.
The problem with screen recordings
We need to record live demos for the TikTok developer application and for prospective SaaS customers. The problem: the Engine dashboard has buttons that can wipe entire Modern Mystic product queues or clear staging test data. If you accidentally click one during a demo recording, you've either deleted real work or shown a future customer that the system can be broken with one click. Neither is good.
Until now, those buttons were on the System settings page — right next to harmless operations like syncing mission data. One wrong tap and the queue was gone. The only protection was an admin session check, which passes automatically when the founder is logged in (which is always during a demo).
The Danger Zone
The fix was a dedicated /admin/danger-zone console that groups every destructive operation — reset MM queue, nuke queue, bulk reject, clear staging test items, purge video history — behind a step-up sudo password gate. Each card has its own password field. The password is a separate SUPERADMIN_PASSWORD environment variable, distinct from the regular AUTH_PASSWORD. If it's not set, it falls back to the login password. But during a demo, you can set it to something you know and the person watching doesn't.
What changed architecturally
First, I stripped all destructive form buttons from the System page and replaced them with a single "Danger Zone" link. Then I created a new page renderer in danger_zone.py with styled cards, password fields, and CSRF protection. Finally, five server routes translate the sudo-authenticated requests to the existing internal endpoints — so the actual reset logic didn't change, only the access layer.
The same PR also fixed a P1 output encoding bug where social post copy-paste was delivering double-escaped HTML entities (') instead of clean apostrophes. It turned out the server-side HTML escaping was encoding the same content twice — once in the Python template and once in the JavaScript template literal. The fix was a single recursive unescape call before the final escape pass.
The lesson for builders
When you're building SaaS for other people to use, design the UI as if you'll be screen-sharing every session. The Danger Zone pattern — explicit, guarded, visually distinct — is better than any "are you sure?" modal. And if you have a double-encoding bug, check your escape layers: the fix is almost always removing one, not adding another.
Want more like this?
Start with the free AI business guide, or explore the full library.
Get the free guide → Back to journal →