Kontrollera webbplatsens säkerhet utan att hacka något

Passiva säkerhetskontroller för webbutiker: TLS-certifikat, HSTS, CSP, nosniff, cookieflaggor, blandat innehåll, gammal jQuery, security.txt och DMARC.

FixReports redaktion10 min läsning

Du kan kontrollera mycket av en webbutiks säkerhetsinställningar utifrån genom att läsa det som webbplatsen redan skickar till varje besökare: TLS-certifikatet, omdirigeringar, HTTP-svarshuvuden (headers), cookies, de skript som laddas och de publika DNS-posterna. De här passiva kontrollerna skickar ingen attacktrafik och kräver ingen inloggning, så de belastar inte butiken mer än ett vanligt besök. De fångar brister i konfigurationen, till exempel ett certifikat som snart går ut, saknad HSTS, osäkra cookies, blandat innehåll eller en jQuery-version med kända sårbarheter. De är inte ett penetrationstest och kan inte bevisa att en butik är säker.

Viktiga punkter

  • Publikt betrodda TLS-certifikat som utfärdats sedan den 15 mars 2026 får vara giltiga i högst 200 dagar, och gränsen sjunker till 100 dagar i mars 2027 och 47 dagar i mars 2029 (CA/Browser Forum (öppnas i en ny flik)).
  • Webbläsare ignorerar HSTS-headern när den skickas över okrypterad HTTP (MDN (öppnas i en ny flik)).
  • CSP-direktivet frame-ancestors fungerar inte i en <meta>-tagg; det måste skickas som en svarsheader (MDN (öppnas i en ny flik)).
  • jQuery-versioner före 3.5.0 påverkas av två XSS-sårbarheter, och CISA lade till en av dem, CVE-2020-11023, i sin katalog Known Exploited Vulnerabilities den 23 januari 2025 (NVD (öppnas i en ny flik)).
  • En security.txt-fil måste innehålla fälten Contact och Expires och ligga på /.well-known/security.txt (RFC 9116 (öppnas i en ny flik)).

Vad räknas som en passiv säkerhetskontroll?

En passiv kontroll läser bara det som webbplatsen eller dess DNS returnerar på en vanlig förfrågan.

Det innebär att ladda publika sidor, läsa certifikatet och svarshuvudena, lista de cookies och skript som en sida sätter och fråga efter publika DNS-poster. En passiv kontroll gissar inte lösenord, skickar inte injektionsnyttolaster (payloads), letar inte efter admin-URL:er och skannar inte portar. Allt nedan kan göras med en webbläsare, curl, openssl och dig.

Hur kontrollerar du ditt TLS-certifikat och när det går ut?

Läs certifikatets datum och namn direkt, och se till att förnyelsen sker automatiskt.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Kontrollera att notAfter ligger med god marginal i framtiden, att certifikatet täcker både example.com och www.example.com om du använder båda (webbläsarens certifikatvisare listar namnen) och att webbläsaren inte visar några varningar. Certifikatens livslängd krymper enligt CA/Browser Forums Baseline Requirements (avsnitt 6.3.2, version 2.3.1 i oktober 2026), efter Ballot SC-081v3 (öppnas i en ny flik), som antogs den 11 april 2025:

Certifikat utfärdatLängsta giltighetstid
Före 15 mars 2026398 dagar
15 mars 2026 till 14 mars 2027200 dagar
15 mars 2027 till 14 mars 2029100 dagar
Från 15 mars 202947 dagar

Med kort livslängd blir manuell förnyelse riskabel, så kontrollera att ditt webbhotell eller certifikatverktyg förnyar automatiskt. Kontrollera också att okrypterad HTTP omdirigeras till HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Du vill se ett 301-svar (eller 308) med en location-header som börjar med https://.

Vilka säkerhetsheaders bör en webbutik skicka?

En liten uppsättning svarshuvuden blockerar vanliga attacker i webbläsaren till nästan ingen kostnad.

HeaderVad den görTypiskt värdeKälla
Strict-Transport-SecuritySäger åt webbläsare att bara använda HTTPS och hindrar användare från att klicka sig förbi certifikatfelmax-age=31536000; includeSubDomainsMDN (öppnas i en ny flik)
Content-Security-Policy: frame-ancestorsStyr vilka webbplatser som får bädda in dina sidor, vilket skyddar mot clickjackingframe-ancestors 'self'MDN (öppnas i en ny flik)
X-Frame-OptionsÄldre styrning av inramning; enligt OWASP gör frame-ancestors den överflödig i webbläsare som stöder detDENY eller SAMEORIGINOWASP (öppnas i en ny flik)
X-Content-Type-OptionsStoppar MIME-sniffning och blockerar skript och stilmallar som levereras med fel typnosniffMDN (öppnas i en ny flik)
Referrer-PolicyBegränsar hur mycket av dina URL:er som skickas till andra webbplatserstrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader för webbläsarens XSS-filter; enligt OWASP kan den skapa XSS-sårbarheter på webbplatser som annars är säkraSätt den inte, eller 0OWASP

Kontrollera vad din butik skickar:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Två varningar. includeSubDomains blockerar alla underdomäner som bara fungerar över HTTP, så kontrollera underdomänerna först. HSTS-förladdning (preload) kräver max-age på minst 31536000 och includeSubDomains, så lägg bara till preload när varje underdomän är redo för HTTPS. En fullständig CSP som begränsar skript är värd att ha, men OWASP påpekar att den är komplicerad att konfigurera och underhålla, och butiker med många appar behöver testa den noggrant.

Har dina cookies attributen Secure, HttpOnly och SameSite?

Sessions- och varukorgscookies bör ha alla tre attributen, och du kan se dem i svarshuvudena Set-Cookie.

AttributEffekt (enligt MDN (öppnas i en ny flik))Där det spelar roll
SecureSkickas bara över HTTPS; webbplatser på okrypterad HTTP kan inte sätta detVarje cookie i en HTTPS-butik
HttpOnlyJavaScript kan inte läsa cookien via document.cookie, vilket hjälper mot XSSInloggningssessioner och varukorgar
SameSite=Lax eller StrictBegränsar när cookien skickas vid förfrågningar mellan webbplatserSessioner; Strict passar för autentiserings- och varukorgscookies
SameSite=NoneSkickas vid förfrågningar mellan webbplatser; måste kombineras med SecureBara inbäddade tredjepartsfunktioner som behöver det

Om inget SameSite-attribut är satt behandlar webbläsare cookien som Lax. Cookies som dina egna skript behöver läsa kan inte vara HttpOnly, så fokusera på dem som identifierar en inloggad kund eller en administratör.

curl -sI https://example.com/ | grep -i "^set-cookie"

Webbläsarens utvecklarverktyg visar samma information, inklusive cookies som sätts av skript efter att sidan har laddats.

Hur hittar du blandat innehåll?

Blandat innehåll (mixed content) är alla resurser som laddas över HTTP på en sida som levereras över HTTPS, och webbläsarens konsol listar dem.

MDN (öppnas i en ny flik) delar in det i två grupper. Bilder, ljud och video är ”upgradable” (uppgraderingsbara): webbläsare begär dem automatiskt över HTTPS. Skript, stilmallar, iframes, typsnitt och fetch()-förfrågningar är ”blockable” (blockerbara): webbläsare blockerar dem, vilket gör att det som var beroende av dem slutar fungera. Uppgraderade förfrågningar till en ren IP-adress blockeras också.

För att hitta det öppnar du konsolen på dina viktigaste mallar (startsida, kollektion, produkt, varukorg) och söker efter http:// i temakoden, sidinnehållet och appinställningarna. Shopifys hjälpcenter säger att varje butikssida med en resurs som inte levereras över HTTPS betraktas som osäker (öppnas i en ny flik), och rekommenderar att du lagrar resurserna hos Shopify eller levererar dem över HTTPS. I WooCommerce bör du kontrollera gammalt inläggsinnehåll och temainställningar om webbplatsen någon gång har körts på http://.

Hur upptäcker du föråldrade JavaScript-bibliotek med kända CVE:er?

Lista de bibliotek som varje sida laddar, läs av deras versioner och jämför dem med National Vulnerability Database.

Börja med jQuery. I webbläsarens konsol returnerar $.fn.jquery den inlästa versionen (jQuery API (öppnas i en ny flik)). Versioner att flagga:

CVEBerörda versionerProblemNVD-poäng (v3.1)
CVE-2020-11022 (öppnas i en ny flik)1.12.0 till före 3.5.0Att skicka obetrodd HTML till metoder som .html() eller .append() kan köra kod6,1 (medel)
CVE-2020-11023 (öppnas i en ny flik)1.0.3 till före 3.5.0Samma sak, för HTML som innehåller <option>-element; i CISA:s KEV-katalog sedan 23 januari 20256,1 (medel)
CVE-2019-11358 (öppnas i en ny flik)Före 3.4.0Prototype pollution via jQuery.extend(true, ...)6,1 (medel)

Båda problemen från 2020 är åtgärdade i jQuery 3.5.0. En sårbar version betyder att den bristfälliga koden finns; om den går att utnyttja beror på hur webbplatsen skickar data till den. WordPress har levererat jQuery 3.5.1 sedan version 5.6 (öppnas i en ny flik), så en gammal jQuery i en WooCommerce-butik tyder på en föråldrad WordPress eller på ett tema eller tillägg som laddar en egen kopia. I Shopify kontrollerar du dina temafiler och de appar som lägger in skript.

Vad är security.txt och behöver din butik en?

Det är en ren textfil som talar om för säkerhetsforskare hur de kan rapportera en sårbarhet till dig.

RFC 9116 (öppnas i en ny flik) (april 2022, en informativ RFC, så det är frivilligt att följa den) säger att filen måste levereras över HTTPS på /.well-known/security.txt som text/plain. Contact och Expires är obligatoriska, och RFC:n rekommenderar ett Expires-datum som ligger mindre än ett år fram i tiden.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

I WooCommerce kan du lägga filen på din server. På en hostad plattform kontrollerar du om du kan publicera en fil på den sökvägen; om inte hjälper det ändå med en tydligt märkt säkerhetskontakt på din kontaktsida.

Hur skyddar DMARC din butik mot förfalskad e-post?

Med DMARC kan du be e-postleverantörer att sätta i karantän eller avvisa e-post som använder din domän i From-adressen utan att klara matchande SPF eller DKIM.

En post med p=none samlar bara in rapporter; den stoppar inte förfalskad e-post. Kunderna förväntar sig orderbekräftelser och lösenordsåterställningar från din domän, så ett nätfiskemejl som visar exakt din domän är värt att blockera. Kontrollera din policy med dig +short TXT _dmarc.example.com, och se RFC 9989 (öppnas i en ny flik) för specifikationen. DMARC omfattar inte domäner som liknar din, bara den domän som publicerar posten.

Vad sköter Shopify, och vad styr du själv i WooCommerce?

Shopify driver servrarna bakom sina butiker, medan en egenhostad WooCommerce-butik lämnar serverinställningarna till dig och ditt webbhotell.

KontrollShopifyWooCommerce (egen hosting)
TLS-certifikatGratis för alla domäner som läggs till i Shopify (öppnas i en ny flik); kan ta upp till 48 timmar för domäner från tredje partDitt webbhotell eller din egen konfiguration
Omdirigering från HTTP till HTTPSPlattformenInställningar i webbservern, CDN:et eller hos webbhotellet
SäkerhetsheadersSkickas av Shopifys servrarWebbserver, CDN eller ett tillägg
CookieflaggorShopifys egna cookies sätts av plattformen; cookies från appar och teman är ditt ansvarWordPress-kärnan, tillägg och server
Blandat innehåll och JS-bibliotekDitt tema, ditt innehåll och dina apparDitt tema, ditt innehåll och dina tillägg
security.txt och DMARCDin domän och din DNSDin domän och din DNS

När vi kontrollerade flera butiker som hostas av Shopify i oktober 2026 innehöll deras svar HSTS med en max-age på ungefär 91 dagar, X-Content-Type-Options: nosniff och en CSP med upgrade-insecure-requests, medan frame-ancestors skilde sig mellan butikerna. Shopify uppger att företaget är certifierat enligt PCI DSS nivå 1 (öppnas i en ny flik). Ditt tema och dina installerade appar är fortfarande ditt ansvar.

För WooCommerce säger WordPress guide för härdning (öppnas i en ny flik) att du ska hålla WordPress och tillägg uppdaterade, ta bort tillägg som du inte använder och fråga ditt webbhotell vilka säkerhetsåtgärder de vidtar.

Varför är det här inte ett penetrationstest?

Ett penetrationstest försöker aktivt genomföra attacker; passiva kontroller observerar bara.

NIST SP 800-115 definierar penetrationstestning som säkerhetstestning där utvärderare efterliknar verkliga attacker för att hitta sätt att kringgå ett systems säkerhetsfunktioner (NIST:s ordlista (öppnas i en ny flik)). Passiva kontroller kan inte se brister på serversidan i tillägg, svaga eller återanvända administratörslösenord, saknad tvåfaktorsautentisering, bristande åtkomstkontroll eller sårbar kod som aldrig syns i sidans källkod. Använd dem som en grundnivå som du kan upprepa när som helst. Vill du ha en djupare försäkran beställer du ett penetrationstest med en skriftlig omfattning, på system som du äger eller har behörighet att testa.

En gratis skanning gör en första genomgång av din butik. Vår Säkerhetsrapport för webbplatsen omfattar de passiva kontrollerna i den här artikeln, från TLS och omdirigeringar till headers, cookies, blandat innehåll, föråldrade bibliotek, security.txt och DMARC, med åtgärder för varje fynd. Som alla passiva granskningar kan den inte garantera att en butik är säker.

Vanliga frågor

Utsätter passiva säkerhetskontroller min butik för risk?

Inte mer än ett vanligt besök. De begär samma publika sidor och DNS-poster som vilken webbläsare eller e-postserver som helst skulle göra, och de försöker inte logga in eller skicka attacknyttolaster.

Kan jag lägga till säkerhetsheaders i Shopify?

Butikens svarshuvuden kommer från Shopifys servrar, så kontakta Shopify Support om en header som du behöver saknas. En CSP-<meta>-tagg i ditt tema kan lägga till vissa direktiv, men MDN påpekar att frame-ancestors inte stöds i <meta>.

Betyder en gammal jQuery-version att min butik har blivit hackad?

Nej. Det betyder att kod med kända sårbarheter laddas, vilket ökar risken om webbplatsen skickar obetrodd HTML till de berörda metoderna. Uppdatera den, eller ta bort temat eller tillägget som laddar den.

Hur länge kan ett TLS-certifikat vara giltigt nu?

Publikt betrodda certifikat som utfärdas från och med den 15 mars 2026 får vara giltiga i högst 200 dagar. Gränsen sjunker till 100 dagar från den 15 mars 2027 och till 47 dagar från den 15 mars 2029.

Är en security.txt-fil obligatorisk?

RFC 9116 är en informativ RFC, så enligt standarden är det frivilligt att publicera filen. Den kostar lite att publicera och ger säkerhetsforskare ett tydligt sätt att nå dig.

Betyder en ren passiv skanning att min butik är säker?

Nej. Den visar att den publika konfigurationen ser rätt ut. Sårbarheter på serversidan, kontosäkerhet och brister i affärslogiken kräver andra tester.

Källor

Alla guider