Lovable Events & Hooks: koppla vidare utan säkerhetsrisk

Vad Lovable har lagt till

Den 27 oktober 2026 presenterade Lovable Events & Hooks i sin changelog. Funktionen låter administratörer och ägare i arbetsytor på Business- och Enterprise-planerna koppla Lovable till en egen tjänst via en HTTPS-endpoint.

Det här är en viktig skillnad mot att låta en användare trycka på en knapp i din app. Lovable tar själv initiativ till anropet när något händer i arbetsytan eller när en handling behöver granskas.

Events skickas efter att en händelse har inträffat. Lovable kan exempelvis meddela din tjänst när ett projekt skapas, publiceras, flyttas till en annan arbetsyta eller raderas. Det passar för sådant som att uppdatera ett internt projektregister, starta en granskningsprocess eller meddela ett annat system om en publicering.

Hooks körs innan en handling får fortsätta. Den hook som finns beskriven vid lanseringen granskar ett meddelande innan det skickas i ett projekts chatt. Din endpoint kan tillåta eller neka meddelandet, exempelvis efter en kontroll efter personuppgifter, hemligheter eller annan känslig information.

Skillnaden kan sammanfattas så här:

• Ett event berättar att något redan har hänt.
• En hook frågar om något får hända.

Det innebär också olika risker. Ett misslyckat event kan normalt hanteras senare. En långsam eller trasig hook kan däremot stoppa en person mitt i arbetet. Du behöver därför behandla events som pålitlig meddelandehantering och hooks som en del av Lovables användarflöde.

Funktionen är inte samma sak som ett fullständigt säkerhetslager över all användning av Lovable. Meddelandehooken omfattar projektchatten, men inte alla andra vägar som ett meddelande kan ta. Exempel som inte omfattas är anrop via Lovable API eller MCP, vissa fristående chattar, röstinmatning och vissa projektflöden. Om målet är att hindra känslig information från att nå externa tjänster måste du alltså granska hela informationsflödet, inte bara slå på en hook.

Säkerhetsgränsen ligger i mottagaren

Lovable signerar sina anrop med en hemlighet som hör till destinationen. Signaturen gör det möjligt för din server att kontrollera att innehållet verkligen kommer från Lovable och inte har ändrats på vägen.

Det räcker inte att endpointens adress är svår att gissa. En publik URL kan hittas, läcka genom loggar eller anropas av någon som vill efterlikna Lovable. Din kod måste verifiera signaturen innan den läser data, startar jobb eller fattar ett beslut.

Verifieringen ska göras mot den oförändrade råa request body som servern tog emot. Om ett ramverk först tolkar JSON och sedan skapar en ny textrepresentation kan tecken, ordning eller blanksteg förändras. Då verifierar du inte längre exakt det innehåll som signerades.

En säker mottagare bör därför arbeta i denna ordning:

• Läs request body som rå text eller råa bytes.
• Hämta Lovables signaturhuvuden.
• Verifiera både signaturen och tidsstämpelns aktualitet.
• Avvisa anropet direkt om verifieringen misslyckas.
• Tolka JSON först efter godkänd verifiering.
• Kontrollera händelsetyp, arbetsyta och projekt innan någon åtgärd körs.

Lovable använder formatet Standard Webhooks och rekommenderar dess verifieringsbibliotek. Att använda ett etablerat bibliotek är säkrare än att själv sätta ihop signatursträngen och jämföra kryptografiska värden.

Spara signeringshemligheten i servermiljön, exempelvis som en miljövariabel eller i en tjänst för hemligheter. Den ska inte finnas i Lovable-appens klientkod, i Git-repot eller i vanliga applikationsloggar. Hemligheten visas vid skapandet av destinationen och kan inte hämtas eller roteras därifrån. Om den försvinner eller misstänks ha läckt behöver destinationen ersättas.

Du kan även konfigurera en bearer token. Se den som ett kompletterande lager, inte som en ersättning för signaturverifiering. Begränsa dessutom endpointens tekniska identitet. En mottagare som bara ska lägga till en rad i ett register behöver inte ha rätt att läsa hela databasen, publicera appar eller administrera arbetsytor.

Bygg events för pålitlig leverans

Events skickas asynkront och kan levereras igen om mottagaren inte svarar som förväntat. Samma händelse kan därför nå din endpoint flera gånger. Leveranser kan också komma i en annan ordning än händelserna inträffade.

Det är normalt för webhooks och ska hanteras i din design. Koden måste vara idempotent, vilket betyder att samma anrop kan behandlas igen utan att skapa en ny oönskad effekt.

Om ett publiceringsevent exempelvis skapar ett granskningsärende får en återleverans inte skapa ytterligare ett likadant ärende. Spara webhook-id i en tabell eller annan beständig lagring och markera när leveransen har tagits emot och behandlats. Lovable behåller samma leverans-id vid återförsök, vilket gör det användbart för deduplicering.

Skilj gärna på att ta emot och att utföra arbetet:

• Endpointen verifierar anropet.
• Den registrerar leveransen och placerar arbetet i en kö.
• Den svarar Lovable med en lyckad HTTP-status.
• En separat process utför integrationen.
• Resultat och fel sparas för uppföljning.

Detta minskar risken att Lovable tolkar ett långsamt externt system som ett misslyckande. Det gör också återförsök enklare att kontrollera. Om exempelvis ett CRM eller ett internt API ligger nere kan jobbet ligga kvar i kön utan att hela webhookmottagaren blir otillgänglig.

Händelsedata för events är avsiktligt begränsad och innehåller främst identifierare och tidsstämplar. Utgå inte från att payloaden innehåller allt du behöver. Om mottagaren måste hämta mer information bör det ske med en separat, behörighetsbegränsad integration och med en tydlig kontroll av att projektet fortfarande finns i rätt arbetsyta.

Var också tolerant mot framtida tillägg. Lovable rekommenderar att mottagaren ignorerar okända JSON-fält. Validera de fält du behöver, men låt inte ett nytt frivilligt fält göra att alla leveranser börjar misslyckas. Själva händelsetypen, exempelvis project.published.v1, ska däremot behandlas uttryckligt så att en ny typ inte råkar utlösa fel logik.

Behandla hooks som en stoppkloss i realtid

Hooks är känsligare eftersom Lovable väntar på ditt beslut. Mottagaren ska svara snabbt med allow eller deny och kan ge en begriplig anledning om meddelandet nekas. Hooks återförsöks inte på samma sätt som events.

När du skapar destinationen väljer du vad som ska hända om hooken får ett tekniskt fel. Ett fail closed-beteende blockerar handlingen när din tjänst inte kan fatta beslut. Det ger en striktare kontroll men innebär att ett driftproblem i din tjänst kan stoppa meddelanden i arbetsytan. Ett fail open-beteende släpper igenom handlingen vid fel, vilket ger bättre tillgänglighet men en svagare säkerhetsgräns.

Valet bör göras utifrån vilken risk kontrollen faktiskt hanterar. En regel som skyddar mot att allvarliga hemligheter lämnar organisationen kan behöva blockera vid osäkerhet. En vägledande kvalitetskontroll bör sällan få stoppa hela arbetsytan för att en extern klassificeringstjänst är nere.

Hookens payload kan innehålla hela meddelandet samt information om avsändare och bilagor. Länkar till bilagor är tillfälligt åtkomliga för den som har länken. Behandla därför både innehåll och länkar som känsliga uppgifter:

• Logga inte hela meddelanden som standard.
• Skicka inte innehållet vidare till fler tjänster än nödvändigt.
• Spara inte bilagor utan ett tydligt ändamål och en gallringsregel.
• Begränsa vem som får läsa felrapporter och granskningsresultat.
• Använd separata testdata när flödet utvecklas.

Om du använder en språkmodell för att klassificera meddelanden måste texten behandlas som opålitlig indata. Ett meddelande kan innehålla instruktioner som försöker påverka klassificeraren. Lägg fasta säkerhetsregler utanför prompten, minimera vilken kontext modellen får och låt inte modellens svar direkt starta privilegierade åtgärder.

Ge också användaren ett användbart nekandemeddelande. Skriv vad som behöver tas bort eller ändras utan att avslöja interna detektionsregler. Ett generiskt fel leder ofta till upprepade försök, medan en konkret förklaring gör kontrollen lättare att följa.

Kontrollera detta före skarp koppling

Innan en Lovable-arbetsyta ansluts till riktiga interna system bör du kunna bocka av följande:

• Endpointen använder HTTPS och tar bara emot avsedd metod.
• Signaturen verifieras mot den råa request body.
• Gamla eller ogiltiga tidsstämplar avvisas.
• Signeringshemligheten finns endast i säker servermiljö.
• Arbetsytans och projektets identifierare kontrolleras.
• Okända händelsetyper avvisas eller ignoreras säkert.
• Nya frivilliga JSON-fält tolereras.
• Events dedupliceras med webhook-id.
• Långsamt arbete körs efter att eventet har kvitterats.
• Mottagaren klarar leveranser i oväntad ordning.
• Hookens felbeteende är ett medvetet verksamhetsbeslut.
• Det finns övervakning för fel, köer och nekade meddelanden.
• Loggar innehåller inte meddelandetext, bilagelänkar eller hemligheter i onödan.
• Tjänstekontot har minsta möjliga behörighet.
• Det går att stänga av destinationen utan en ny driftsättning.
• Testet omfattar dubbla events, felaktiga signaturer och otillgängliga beroenden.

Testa först med en separat destination och ett projekt utan verkliga personuppgifter eller produktionshemligheter. Kontrollera leveranshistoriken i Lovable och jämför den med mottagarens loggar. Du ska kunna följa ett anrop från mottagning till genomförd eller avbruten åtgärd utan att behöva lagra hela det känsliga innehållet.

Bestäm också vem som äger integrationen efter lanseringen. Någon behöver reagera när certifikat löper ut, hemligheter misstänks ha läckt, regler blockerar fel meddelanden eller ett externt system ändrar sitt API. Events & Hooks är inte bara en inställning i Lovable – det är en ny produktionsintegration som behöver drift, åtkomstkontroll och en plan för incidenter.

När en Lovable-prototyp ska börja påverka riktiga data och arbetsflöden behöver integrationen behandlas som steget från prototyp till produkt.

---

Källa: Lovable changelog