Nämä mallit on sidottu nykyiseen arkkitehtuuriin: staattinen laplandailab.fi (Cloudflare Pages), sekä erilliset demo-appit Vercelissä/Cloudflaressa.
Miksi: Staattinen sivu on julkinen; kaikki selaimeen päätyvä on luettavissa.
Milloin: Aina kun demo tarvitsee API-avaimen, webhookin tai admin-tokenin.
Tässä toteutuksessa: laplandailab.fi-sivuilla käytetään vain julkisia linkkejä ja staattista sisältöä. Avaimet pidetään demoalustojen ympäristömuuttujissa, ei HTML:ssä, JS:ssä tai Gitissä.
Miksi: Demo-linkit menevät kolmannen osapuolen ympäristöihin; tabnabbing- ja kontekstiriskit pitää rajata.
Milloin: Kun linkitetään Vercel/ChatGPT/GitHub- tai muihin ulkoisiin palveluihin.
Tässä toteutuksessa: ulkoiset linkit avataan uudessa välilehdessä ja niissä käytetään aina rel="noopener noreferrer". Samalla pidetään sisäiset sivusiirtymät omassa tabissa.
Miksi: Erillisissä demoissa riski kertyy paketeista, vaikka pääsivusto on kevyt staattinen.
Milloin: Ennen julkaisua sekä kuukausirytmillä aktiivisille demoille.
Tässä toteutuksessa: tarkista käytetyt paketit, poista käyttämättömät, päivitä turvallisuuskorjaukset ja validoi että buildi pysyy toistettavana ilman uusia raskaita riippuvuuksia.
Miksi: Case-sivu kertoo demon tarkoituksen ilman, että mukana kulkee tuotantodataa tai henkilötietoa.
Milloin: Kun demo esittelee toimintalogiikkaa, käyttöpolkua tai UI-prototyyppiä.
Tässä toteutuksessa: case-kuvaukset ja linkit julkaistaan erikseen, mutta data pidetään synteettisenä/anonymisoituna demo-appissa. Lokiin ei kirjoiteta salaisuuksia tai henkilötietoa.
Muistisääntö: jos kontrolli ei näy staattisessa sivussa, se dokumentoidaan demo-repon README:hen ja julkaisuchecklistaan ennen deployta.
Takaisin: Tietoturva · Tietoturvakäytännöt demoissa
