Sikkerhed

Vores sikkerhedsmodel i én sætning: der er intet på en server at angribe. Alt herunder kan falsificeres fra dine DevTools.

Arkitektur

Generatoren er en statisk single-page-applikation, der serveres fra Cloudflare Pages: ingen brugerkonti, ingen godkendelse, og ingen backend-kodesti nogen steder i genereringsflowet. Alle QR-genererings-, kodnings-, scannings- og renderingsoperationer kører udelukkende i din browser. Ét lille serverless-endpoint sidder ved siden af og er nævnt her i stedet for skjult: /api/contact (kontaktformularen, som gemmer det, du indsender, i Cloudflare D1 og mailer det til os). Det kaldes ikke, mens du laver en QR-kode; URL-sikkerhedstjekkeren er et separat produkt på check.qr.abundera.ai. Tjek om en QR-kode er sikker

Trusselsmodel

Fordi generatoren ikke indsamler, gemmer eller transmitterer brugerdata (de to endpoints ovenfor håndterer kun det, du eksplicit sender dem), gælder de mest almindelige webapptrusler — tyveri af legitimationsoplysninger, databasebrud, session-kapring, serverside-injektion — ikke for den. Den resterende angrebsflade er det statiske asset-bundt (HTML, CSS, JavaScript), der serveres fra vores oprindelse. Vi designer med antagelsen om:

Content Security Policy — pr. direktiv

Politikken nedenfor læses fra den udrullede _headers-fil, når denne side bygges, så den ikke kan afvige fra det, edge'n sender. Verificer den i svarheaderne for enhver anmodning.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://abundera.ai 'wasm-unsafe-eval' https://challenges.cloudflare.com;
  worker-src 'self' blob:;
  style-src 'self' 'unsafe-inline' https://abundera.ai;
  font-src 'self';
  img-src 'self' data: blob: https:;
  connect-src 'self' https: https://challenges.cloudflare.com;
  frame-src 'self' https://challenges.cloudflare.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self'

Hvad hvert direktiv lader os gøre, og hvor det kompromitterer:

Hvad CSP ikke kan gøre

CSP begrænser, hvorfra browseren vil indlæse kode. Den kontrollerer ikke, hvad indlæst kode gør. Hvis vores oprindelse blev kompromitteret, det første punkt i trusselsmodellen, ville angriberens script køre med de samme tilladelser som vores, inklusive connect-src- og img-src-tilladelserne ovenfor. Vores forsvar mod det ligger opstrøms for CSP: deploys går ud gennem én Cloudflare-konto med afgrænsede tokens, asset-filnavne er indholds-hashede, så en udskiftet fil ændrer hver URL, der refererer til den, og service workeren cacher kun same-origin GET-svar. Manifestet beskriver sitet, som det er leveret. Det er ikke en påstand om, at ingen webside nogensinde kunne sende data et sted hen, og vi vil hellere have, at du holder os til det snævrere, efterprøvelige udsagn.

Forskellige CSP-politikker gælder for /bio/* (lempet img-src for brugerleverede avatarer) og /embed/* (lempet frame-ancestors for intentionel indlejring). Begge er dokumenteret i site/_headers.

Transport + framing-headere

Service worker

Vores service worker (site/sw.js) cacher kun same-origin-assets. Fetch-handleren afviser eksplicit cross-origin-anmodninger og ikke-GET-metoder — du kan læse logikken i /sw.js (kildekoden leveres ikke-minificeret nok til at følge med). Cache-skrivninger er pakket ind i event.waitUntil(), så de ikke kan droppes midt i en navigation.

Input-sanitering

Alle renderingsstier, der accepterer brugerinput, behandler det som upålidelig tekst:

Cross-origin billedhentning

Når en bruger indsætter en https:-URL som et vCard-foto eller logo, henter browseren det under CORS og vores CSPs img-src-tilladelsesliste. Billedet gengives til et canvas. Det bliver aldrig levende DOM, kører aldrig som kode og når aldrig vores oprindelse — hentningen er browser → eksternt billede, og resultatet males klientsiden. En angriber, der kontrollerer en ekstern billed-URL, kan spore, at URL'en blev indlæst (en logpost på deres egen server), men kan ikke eksfiltrere noget fra vores side.

Subresource Integrity (SRI)

Al JavaScript og CSS, vi leverer, er same-origin. Vi indlæser ikke tredjeparts-scripts eller -stylesheets, så SRI-hashes er ikke relevante. Hvis vi nogensinde indlæser et tredjeparts-asset, leverer vi en SRI integrity-attribut på det og dokumenterer hash-opdateringsprocessen på denne side.

Rapportering af en sårbarhed

Hvis du opdager et sikkerhedsproblem, der påvirker Abundera QR — hvad enten det er i vores kode, vores deployment eller i en afhængighed, vi leverer — bedes du rapportere det privat til security@abundera.ai. Vi sigter mod at triagere inden for 72 timer. Du kan også kontakte os via kontaktoplysningerne i vores /.well-known/security.txt-fil.

Ingen bug-bounty (endnu)

Vi tilbyder i øjeblikket ikke betalte bounties, men hver bekræftet gyldig rapport modtager kredit i ændringsloggen og vores offentlige tak.

Verificer alt ovenstående

Hvert udsagn på denne side kan falsificeres fra din browsers DevTools uden at stole på os:

Kontakt

Sikkerhedsoplysninger: security@abundera.ai

Sidst opdateret: 2026-09-03. Næste gennemgang: 2026-12-03.