These patterns are tied to the current architecture: static laplandailab.fi on Cloudflare Pages, plus separate demo apps on Vercel/Cloudflare.
Why: A static frontend is public; anything shipped to the browser can be read.
When: Any demo needs an API key, webhook secret, or admin token.
In this site: laplandailab.fi only ships public links and static content. Secrets stay in demo-platform environment variables, never in HTML, JS, or Git.
Why: Demo links open third-party systems, so tabnabbing and context leaks must be limited.
When: Linking to Vercel, ChatGPT, GitHub, or any external service.
In this site: external links open in a new tab and always include rel="noopener noreferrer". Internal navigation stays in the same tab.
Why: Most dependency risk sits in separate demo apps, even if the main site is static and minimal.
When: Before each release and monthly for active demos.
In this site: review installed packages, remove unused ones, apply security updates, and keep builds reproducible without adding heavy libraries by default.
Why: Case pages should communicate intent without carrying production data or personal data.
When: Demonstrating workflow logic, user flows, or UI prototypes.
In this site: case descriptions and links are published here, while demo apps use synthetic/anonymized data. Logs must not include credentials or personal identifiers.
Rule of thumb: if a control is not visible in this static site, document it in the demo repo README and release checklist before deploy.
Back to: Security · Security practice in demos
