Säkerhet & infrastruktur - Säkerhet & datahantering hos Siteflow

1. Översikt — så jobbar vi med säkerhet

Säkerhet är inte en kryssruta vi bockar av efter lansering — det är en kontinuerlig process som löper genom hela leveransen. Från det att en besökare når er hemsida via en krypterad HTTPS-förbindelse, till att ett formulär skickar leadet till vårt CRM, till att en backup skrivs till geo-redundant lagring varje natt — varje länk i kedjan har granskats och härdats.

Vi följer principer som defence in depth (flera försvarslager i stället för ett enda perimeterskydd), least privilege (minsta möjliga åtkomst för varje system och anställd) och secure by default (säkra inställningar aktiverade direkt, utan att ni som kund behöver be om det). I praktiken innebär det att en sajt vi levererar har moderna säkerhetsheaders, kryptering, bot-skydd och övervakning aktiverat från första dagen — inte som ett tillval.

Den här sidan beskriver vår säkerhetsmodell i klartext så att ni som kund — eller revisor, säkerhetsansvarig eller upphandlare — kan göra en informerad bedömning. Behöver ni djupare dokumentation för en riskanalys eller upphandling skickar vi gärna vår tekniska säkerhetsbilaga på begäran.

2. Teknisk säkerhet på applikationsnivå

All trafik till och från hemsidor som drivs av Siteflow är krypterad med moderna standarder. Vi använder ingen egen certifikatutfärdare och låter aldrig en sajt gå live utan giltigt certifikat.

2.1 HTTPS överallt med TLS 1.3

Alla våra sajter levereras uteslutande över HTTPS. Vi använder TLS 1.3 som primärt protokoll med fallback till TLS 1.2 för äldre klienter. Äldre versioner (TLS 1.0, TLS 1.1, SSLv3) är helt avstängda. Certifikaten förnyas automatiskt via Let's Encrypt eller Cloudflare och övervakas så att vi får larm 30 dagar innan utgång — vi tillåter inte att ett certifikat hinner gå ut i produktion.

Alla HTTP-anrop på port 80 omdirigeras med 308 Permanent Redirect till HTTPS i edge-lagret — innan trafiken ens når applikationen. Det innebär att en besökare aldrig kan råka skicka data okrypterat, även om en länk skulle vara hårdkodad till http://.

2.2 HSTS med preload

För att eliminera risken för man-in-the-middle-attacker via okrypterad fallback skickar vi alltid en Strict-Transport-Security-header med max-age=63072000; includeSubDomains; preload. Det betyder att webbläsare i två år framåt vägrar prata HTTP med er domän överhuvudtaget — även om en länk pekar fel. När domänen är stabil ansöker vi om plats på Chromes HSTS preload-lista, vilket bygger in skyddet direkt i alla större webbläsare innan ens första besök sker.

2.3 Content Security Policy (CSP)

Cross-site scripting (XSS) är fortfarande en av de vanligaste attackvektorerna mot webbsidor. Vi skickar därför en strikt Content-Security-Policy som vitlistar exakt vilka domäner som får ladda script, bilder, typsnitt och stilar. Inline-script körs enbart med nonce, vilket betyder att ett injicerat <script>-element från en angripare aldrig kommer att exekvera ens om en sårbarhet skulle finnas i ett annat lager.

Policyn loggar även rapporter om eventuella brott via report-uri, så att vi får signal om någon försöker injicera kod eller om en tredjepartsleverantör börjat ladda nya resurser som inte är godkända. Vi granskar rapporterna veckovis.

2.4 Säkerhetsheaders och hardening

Utöver CSP skickar vi en komplett uppsättning säkerhetsheaders på varje response:

• X-Frame-Options: DENY — förhindrar att sajten bäddas in i en iframe på annan domän, vilket stoppar klassiska clickjacking-attacker.
• X-Content-Type-Options: nosniff — tvingar webbläsaren att respektera deklarerad Content-Type istället för att gissa, vilket eliminerar MIME-sniffing-attacker.
• Referrer-Policy: strict-origin-when-cross-origin — begränsar vilken referrer-information som läcker till externa domäner när besökaren klickar på en utgående länk.
• Permissions-Policy — stänger av webbläsar-API:er som sajten inte använder (kamera, mikrofon, geolocation, USB) så att en eventuell sårbarhet inte kan utnyttja dem för spårning eller åtkomst till enheten.
• Cross-Origin-Opener-Policy: same-origin och Cross-Origin-Resource-Policy: same-origin — isolerar dokumentet från andra browsing-contexts, vilket är ett modernt skydd mot Spectre-liknande sidokanalattacker.

Konfigurationen verifieras regelbundet via securityheaders.com och Mozilla Observatory där vi siktar på betyget A eller bättre på varje produktionssajt.

2.5 DDoS-skydd och WAF

All inkommande trafik passerar genom Cloudflare innan den når våra servrar. Cloudflare absorberar volymbaserade DDoS-attacker (Layer 3/4) i sitt anycast-nätverk och har historiskt mitigerat attacker över flera Tbit/s utan inverkan på underliggande tjänster. På applikationsnivå (Layer 7) körs en Web Application Firewall som blockerar kända attackmönster — SQL-injection, XSS, path traversal, kommandoinjektion — innan de når vår applikationskod.

Som extra lager utnyttjar vi Fly.io:s inbyggda DDoS-mitigering i deras edge-noder, vilket innebär att även trafik som skulle slippa förbi Cloudflare blockeras närmare källan. Formulär skyddas dessutom med Cloudflare Turnstile — en cookieless utmaning som filtrerar bort bottar utan att irritera riktiga användare med pussel.

3. Datalagring och GDPR

Var data fysiskt lagras spelar både roll juridiskt (GDPR och Schrems II) och tekniskt (latens och driftsäkerhet). Vår grundprincip är enkel: så mycket som möjligt ska ligga i EU, och allt som lagras utanför EU måste ha laglig grund och dokumenterade skyddsåtgärder.

3.1 EU-hosting i Stockholm

Våra applikationsservrar och databaser ligger primärt i Fly.io:s region arn — fysiskt placerad i ett datacenter i Stockholm. Det betyder att svenska besökares trafik aldrig behöver lämna landet för att rendera en sida eller spara ett formulärinskick, och att svenska myndighetskunder kan ange Sverige som lagringsland i sin personuppgiftsförteckning.

För redundans replikerar vi vissa databaser till en sekundär EU-region (Frankfurt eller Amsterdam) så att en regional incident i Stockholm inte innebär dataförlust. Replikan ligger fortfarande inom EU/EES och omfattas av samma GDPR-skydd som primären.

3.2 GDPR-compliance

Hela vår tjänst är designad med GDPR som utgångspunkt — inte som ett eftermonterat lager. Det innebär bland annat:

• Cookie-banner på samtliga sajter som kräver aktivt samtycke innan spårningscookies aktiveras, i linje med IMY:s tillsynspraxis från april 2025.
• Loggning av samtycke med tidsstämpel och version av banner-texten, så att samtycke kan styrkas i efterhand.
• Automatisk gallring av leadsdata och formulärinskick baserat på den retention som ni som kund anger.
• Stöd för registerutdrag, radering och rättelse via vårt kundgränssnitt eller på begäran från oss.
• Pseudonymisering av IP-adresser i analys- och felrapporteringsverktyg.

För detaljer om vilka personuppgifter vi behandlar, varför och hur länge — läs vår integritetspolicy.

3.3 Personuppgiftsbiträdesavtal (DPA)

Eftersom Siteflow behandlar personuppgifter för er räkning är vi personuppgiftsbiträde enligt artikel 28 GDPR och ni är personuppgiftsansvariga. Vi tecknar ett personuppgiftsbiträdesavtal (DPA) med samtliga kunder som ett standardled i avtalsskrivningen. DPA:n beskriver:

• Föremålet och varaktigheten för behandlingen.
• Behandlingens art och syfte samt kategorier av personuppgifter.
• Tekniska och organisatoriska säkerhetsåtgärder enligt artikel 32.
• Lista över underbiträden (Fly.io, Cloudflare, Resend, Stripe, Sentry m.fl.) och rutiner för att meddela byten.
• Bistånd vid begäranden från registrerade och vid eventuell incidenthantering.
• Återlämning eller radering av data när avtalet upphör.

Behöver ni en kopia av vår standard-DPA innan ni signerar huvudavtalet skickar vi den utan extra kostnad. Vi accepterar också i de flesta fall er egen DPA-mall om den följer GDPR:s minimikrav.

4. Backuper och redundans

Data som inte säkerhetskopieras tillhör inte er — den tillhör nästa hårddiskfel. Därför är backup-strategin en av de viktigaste komponenterna i vår säkerhetsmodell.

4.1 Daglig backup

Samtliga produktionsdatabaser backas upp automatiskt varje natt. Backuperna är fulla snapshots, inte inkrementella, vilket gör återställning snabbare och enklare att verifiera. Ett backupjobb misslyckas inte tyst: om en backup inte slutförts inom förväntat tidsfönster larmar vårt övervakningssystem så att vi kan agera samma morgon.

4.2 Retention i 30 dagar

Vi behåller dagliga backuper i 30 dagar rullande. Det ger marginal att återställa från en korruption eller en oavsiktlig radering som upptäcks först efter någon vecka. För kunder med högre krav (t.ex. revisorer eller verksamhet med lagstadgad arkiveringsplikt) erbjuder vi förlängd retention upp till 7 år som tillval.

4.3 Geo-redundant lagring

Backupfilerna lagras i en separat region från produktionsdatabasen och i ett annat geografiskt område inom EU/EES. Det betyder att en brand, översvämning eller annan fysisk incident i Stockholm-datacentret inte kan ta ut både originalet och backupen samtidigt. Backupfilerna är dessutom krypterade i vila med AES-256 och nycklarna roteras kvartalsvis.

Återställningstest körs minst en gång per kvartal — vi återställer en backup till en isolerad miljö och verifierar att data är intakt. En backup som aldrig har återställts är ingen backup, det är en förhoppning.

5. Incident response och felmonitoring

Även den bästa säkerhetsarkitektur garanterar inte att inget händer. Skillnaden mellan en bra och en dålig leverantör är hur snabbt incidenten upptäcks, hanteras och kommuniceras.

5.1 Övervakning och felrapportering

Vi använder Sentry för automatisk fel- och prestandaövervakning av samtliga produktionssajter och bakomliggande tjänster. Sentry fångar oväntade exceptions, JavaScript-fel hos slutanvändare, långsamma databasfrågor och avvikande HTTP-status. IP-adresser scrubbas innan de skickas till Sentry så att vi inte skickar mer personuppgifter än nödvändigt utanför EU/EES.

Utöver Sentry har vi externa uptime-prober som kontaktar varje sajt minst varje minut från flera geografiska punkter. Om en sajt inte svarar på två konsekutiva prober larmar systemet vår jourtelefon — även mitt i natten.

5.2 72-timmars rapportering till IMY

Vid en personuppgiftsincident — exempelvis obehörig åtkomst, dataläckage eller förlust av uppgifter — agerar vi enligt en dokumenterad incident response-plan. För personuppgiftsansvariga (våra kunder) är det kritiskt att veta att vi som biträde uppfyller artikel 33 GDPR: vi meddelar er utan onödigt dröjsmål och senast inom 24 timmar efter att vi fått kännedom om incidenten, så att ni i sin tur hinner rapportera till Integritetsskyddsmyndigheten (IMY) inom 72 timmar.

Meddelandet innehåller minst: incidentens natur, kategorier och ungefärligt antal berörda registrerade, troliga konsekvenser, vidtagna eller föreslagna åtgärder och kontaktuppgifter för uppföljning. Vi bistår också med tekniskt underlag om ni behöver bilägga loggar eller tidslinjer till er IMY-anmälan.

5.3 Information till berörda kunder och besökare

Om incidenten medför hög risk för registrerades fri- och rättigheter (artikel 34 GDPR) bistår vi också med utkast till information till berörda slutanvändare. Detta kan omfatta e-postutskick, in-app-notiser eller offentlig kommunikation på sajten. Vi tar fram förslag på ordval som är tydligt, faktabaserat och utan onödig juridisk distans — men slutligt beslut om kommunikation fattas alltid av er som personuppgiftsansvariga.

6. Penetrationstest och sårbarhetsskanning

Egen kod blir blind för sina egna sårbarheter — därför kompletterar vi vår interna granskning med externa tester och automatiserade skanningar.

Penetrationstest beställs minst en gång per år av en oberoende säkerhetspartner med erfarenhet av modern webbinfrastruktur. Testet täcker både applikationslagret (OWASP Top 10, authentication, autorisering, sessions) och infrastrukturlagret (DNS, TLS, header-konfiguration, exponerade endpoints). Rapportens fynd prioriteras enligt CVSS, och allt som klassas som High eller Critical åtgärdas inom 14 dagar.

Sårbarhetsskanning körs kontinuerligt. Beroenden i våra Node.js- och TypeScript-projekt kontrolleras mot CVE-databaser via automatiserade verktyg vid varje pull request, och nya kritiska sårbarheter (Log4Shell, npm-supply-chain-attacker etc.) flaggar omedelbart. Vi använder också Cloudflares och Fly.io:s egna infrastrukturskanningar för att fånga felkonfigurationer i edge-lagret.

Resultat och remediation från senaste penetrationstest delas på begäran med kunder som har avtal med oss — typiskt under sekretess.

7. Säkerhetskultur hos anställda

Den mest sofistikerade tekniska säkerhetsarkitekturen kan brytas av ett enda phishing-mail som en oförsiktig medarbetare öppnar. Därför behandlar vi mänsklig säkerhet som en lika viktig komponent som teknisk.

Alla anställda och konsulter genomgår en obligatorisk säkerhetsintroduktion vid onboarding som täcker grundläggande hygien: starka unika lösenord, hantering av MFA-tokens, identifiering av phishing och social engineering, hantering av personuppgifter i vardagen och eskaleringsrutiner vid misstänkt incident. Utbildningen repeteras minst en gång per år och uppdateras när nya hotbilder framträder.

För tekniska medarbetare gäller dessutom:

• Hårdvarunycklar (YubiKey eller motsvarande) för åtkomst till produktionssystem och GitHub.
• Single sign-on med MFA för samtliga molntjänster — ingen lösenordsdelning, inga delade konton.
• Princip om minsta privilegium — utvecklare har inte produktionsåtkomst som standard, utan måste höja behörighet temporärt med audit-log.
• Krypterade hårddiskar (FileVault eller motsvarande) på samtliga arbetslaptops, med automatisk lockscreen efter 5 minuter inaktivitet.
• Säker hantering av API-nycklar och hemligheter via centraliserad secret manager — aldrig i klartext i Git eller chat.

När en medarbetare slutar revokeras samtliga accesser samma dag, hårdvarunycklar samlas in och konton inaktiveras enligt en checklista som signeras av två personer.

8. Rapportera en säkerhetsbrist

Om ni — eller en oberoende säkerhetsforskare — upptäcker en sårbarhet i en sajt eller tjänst som drivs av Siteflow vill vi gärna veta det innan den blir publik. Vi uppskattar ansvarsfull rapportering och svarar normalt inom ett arbetsdygn.

Rapportera en säkerhetsincident eller sårbarhet:
E-post: security@siteflow.se
Vid akut incident utanför kontorstid — ring vår jourtelefon: +46 10 189 84 80

Inkludera om möjligt: beskrivning av sårbarheten, steg för att återskapa, vilken sajt eller tjänst som påverkas och eventuella skärmdumpar eller proof-of-concept. Vi accepterar krypterad e-post via PGP — fingerprint skickas på begäran.

Vi har för närvarande inget formellt bug bounty-program, men vi erkänner publikt (med ert tillstånd) säkerhetsforskare som rapporterar giltiga sårbarheter på ett ansvarsfullt sätt, och vi vidtar inga rättsliga åtgärder mot forskare som följer god praxis för coordinated disclosure.

9. Frågor och ytterligare information

Behöver ni djupare dokumentation för en upphandling, en riskanalys eller en revision — kontakta oss så delar vi:

• Tekniska säkerhetsbilagan med detaljerad arkitekturöversikt.
• Lista över aktuella underbiträden och deras compliance-certifikat.
• Sammanfattning av senaste penetrationstest.
• Vår incident response-plan i fullständig version.
• DPA-mall (svenska eller engelska) inför avtalsskrivning.

Siteflow Stockholm AB
Varuvägen 9, 125 34 Älvsjö
Säkerhetsärenden: security@siteflow.se
Allmänna frågor: hello@siteflow.se
Telefon: +46 10 189 84 80

Senast uppdaterad: 26 maj 2026.