Tjek om din hjemmeside er sikker: fem ting, før du deler din Lovable-webapp

Du har bygget en webapp i Lovable. Eller med ChatGPT, i Bolt, v0 eller Replit, eller ved at snakke med Claude. Den virker. Du har vist den til en ven på din bærbare, og vennen var imponeret. Nu vil du sende linket til en kunde – og en lille stemme spørger, om det nu også er en god idé.

Stemmen har ret i at spørge. Ikke fordi værktøjet har gjort et dårligt stykke arbejde, men fordi det byggede det, du bad om, og ingen bad om de kedelige dele. Her er fem af dem, du selv kan tjekke i eftermiddag uden at læse en eneste linje kode.

Har du bygget den med ChatGPT i stedet – ved at bede om koden og sætte den ind stykke for stykke – er de fem tjek de samme. Den eneste forskel er, at ingen har samlet stykkerne for dig, så tjek 4 tæller dobbelt.

1. Åbn din egen webapp som en fremmed

Log ud. Åbn et privat browservindue. Sæt det link ind, du var ved at dele – og prøv så de links, du normalt ikke ville klikke på: indstillingssiden, admin-siden og adressen på en post, hvor du ændrer tallet til sidst.

Det, du leder efter, er alt det, der åbner sig, når det ikke burde. En admin-side, der vises uden login. En kundes oplysninger, der dukker op, når du ændrer tallet i adresselinjen. En side, der »indlæser« i al evighed – det betyder som regel, at den prøvede at hente noget, den ikke måtte, og at ingen har fortalt den, hvad den så skal gøre.

Finder du noget af det, så stop her. Det er den fejl, vi oftest ser i webapps, der er bygget hurtigt – og den, der ender som et skærmbillede et offentligt sted.

2. Spørg værktøjet, hvor nøglerne ligger

Din webapp taler med andre tjenester: en database, en AI-model, en mailtjeneste, måske en betalingsløsning. Hver af dem har givet dig en nøgle – en lang række bogstaver og tal, der virker som en adgangskode. Spørgsmålet er, hvor din app gemmer dem.

Du behøver ikke finde dem selv. Spørg det værktøj, du byggede med, på almindeligt dansk: »Kommer der nogen API-nøgler eller hemmeligheder fra den her app ud i browseren, eller ligger der nogen i repositoriet?« Spørg så igen på en anden måde: »Lav en liste over alle miljøvariabler, og hvor hver af dem bruges.« Værktøjerne er gode til at svare, når man spørger direkte, og dårlige til at sige det af sig selv.

En nøgle, der når ud i browseren, kan læses af alle, der åbner din app. Hænger der et kreditkort bag nøglen, er det sådan, de overraskende regninger opstår.

3. Find ud af, hvad der koster penge pr. klik

Skriv en liste over alle de tjenester, din webapp bruger. Svar for hver af dem på ét spørgsmål: Betaler jeg et fast beløb, eller betaler jeg pr. brug? En AI-model er næsten altid pr. brug. Det samme gælder mail, sms, kort og fillagring, når man kommer over den gratis mængde.

For hver tjeneste, der koster pr. brug: Log ind på tjenestens hjemmeside og find to indstillinger – et forbrugsloft og en forbrugsalarm. Slå begge til. Loftet stopper regningen, og alarmen siger til, før den når derop. De fleste tjenester har dem. De fleste apps, der er bygget på en eftermiddag, har ingen af dem slået til.

Stil så værktøjet ét spørgsmål mere: »Kan en besøgende, der ikke er logget ind, udløse noget, der koster penge?« Er svaret ja, er din gratis demoside en knap, som alle på internettet kan trykke på, så tit de vil.

4. Tjek, hvad der står i dit navn

Tre ting bør ligge på en konto, du selv styrer, med en adgangskode, du kender, og en mailadresse, du læser: domænet, hostingen og koden.

Domænet er den adresse, folk taster ind. Hostingen er der, hvor webappen kører. Koden er selve appen, og den bør ligge i et repository (GitHub er det almindelige), som tilhører dig – ikke kun inde i det værktøj, der byggede den. Forsvinder værktøjet, hæver det priserne eller låser din konto, er repositoriet det, der lader dig gå med din app under armen.

Mange værktøjer kan kobles til din egen GitHub med et par klik. Er dit ikke koblet på endnu, så gør det, før du deler noget.

5. Lav den kedelige side

Indsamler din webapp noget som helst om en person – et navn, en mailadresse, et foto – skal den have en privatlivspolitik, der siger, hvad du indsamler, og hvorfor. Er du i Europa, eller er dine kunder det, og bruger appen cookies til andet end at holde folk logget ind, skal den have et cookie-banner, hvor man kan sige nej. Og et eller andet sted skal der være en måde at få fat i dig på.

Ikke noget af det er spændende. Men det er forskellen på en webapp, en virksomhed kan bruge, og en, en virksomhed ikke kan være bekendt at bruge. Et værktøj skriver gerne en privatlivspolitik til dig, hvis du beder om det. Læs den, før du udgiver den, for den beskriver, hvad en typisk app gør – ikke hvad din gør.

Det, en tjekliste ikke kan

Alt det ovenstående er tjek, du laver udefra. De fortæller dig, om døren står åben. De fortæller dig ikke, hvor mange andre døre der er.

Da en fremmed brugte en funktion i vores eget produkt, Tolkra, præcis som den var bygget, til at sende svindelmails fra vores domæne, havde den knap, de trykkede på, bestået alle tjek udefra. Den tjekkede, at man var logget ind. Det, den ikke tjekkede, var, om man havde noget at gøre med den person, mailen gik til. At finde det krævede, at man læste koden – og at finde de fire andre steder, hvor den samme antagelse var gjort, tog en dag. Vi har skrevet hele historien op, fordi det er den dag, de fleste hurtigt byggede webapps er på vej mod.

Så lav de fem tjek. Består de alle, har du udelukket de mest almindelige måder at blive til grin på. Vil du derefter have nogen til at læse koden og fortælle dig på almindeligt dansk, hvad der ellers er, så er det det, en gennemgang er til: en halv dag og en skriftlig rapport. Den første snak – et tjek på 25 minutter – er gratis.