Sikkerhetssjekker du kan kjøre på nettstedet uten å hacke noe

Passive sikkerhetssjekker for nettbutikker: utløp av TLS-sertifikat, HSTS, CSP, nosniff, cookie-flagg, blandet innhold, gammel jQuery, security.txt og DMARC.

FixReports-redaksjonen10 min lesing

Du kan sjekke mye av sikkerhetsoppsettet til en nettbutikk utenfra ved å lese det nettstedet allerede sender til alle besøkende: TLS-sertifikatet, omdirigeringer, HTTP-svarheadere, informasjonskapsler (cookies), skriptene som lastes inn, og de offentlige DNS-postene. Disse passive kontrollene sender ingen angrepstrafikk og krever ingen innlogging, så de belaster butikken ikke mer enn et vanlig besøk. De fanger opp hull i konfigurasjonen, som et sertifikat som snart utløper, manglende HSTS, usikre informasjonskapsler, blandet innhold eller en jQuery-versjon med kjente sårbarheter. De er ikke en penetrasjonstest og kan ikke bevise at en butikk er sikker.

Hovedpunkter

  • Offentlig klarerte TLS-sertifikater som er utstedt fra og med 15. mars 2026, kan maksimalt være gyldige i 200 dager. Grensen synker til 100 dager i mars 2027 og til 47 dager i mars 2029 (CA/Browser Forum (åpnes i en ny fane)).
  • Nettlesere ignorerer HSTS-headeren når den sendes over vanlig HTTP (MDN (åpnes i en ny fane)).
  • CSP-direktivet frame-ancestors fungerer ikke i en <meta>-tagg; det må sendes som en svarheader (MDN (åpnes i en ny fane)).
  • jQuery-versjoner før 3.5.0 er berørt av to XSS-sårbarheter, og CISA la 23. januar 2025 en av dem, CVE-2020-11023, til i katalogen Known Exploited Vulnerabilities (NVD (åpnes i en ny fane)).
  • En security.txt-fil må inneholde feltene Contact og Expires og ligge på /.well-known/security.txt (RFC 9116 (åpnes i en ny fane)).

Hva regnes som en passiv sikkerhetssjekk?

En passiv sjekk leser bare det nettstedet eller DNS-en returnerer på en vanlig forespørsel.

Det betyr å laste inn offentlige sider, lese sertifikatet og svarheaderne, liste opp informasjonskapslene og skriptene en side setter og laster inn, og slå opp offentlige DNS-poster. En passiv sjekk gjetter ikke passord, sender ikke injeksjonsdata (payloads), sonderer ikke administrasjons-URL-er og skanner ikke porter. Alt nedenfor kan gjøres med en nettleser, curl, openssl og dig.

Hvordan sjekker du TLS-sertifikatet og når det utløper?

Les datoene og navnene i sertifikatet direkte, og sørg for at fornyelsen er automatisert.

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

Sjekk at notAfter ligger god tid frem i tid, at sertifikatet dekker både example.com og www.example.com hvis du bruker begge (sertifikatvisningen i nettleseren viser navnene), og at nettleseren ikke viser noen advarsler. Levetiden for sertifikater blir kortere etter CA/Browser Forums Baseline Requirements (avsnitt 6.3.2, versjon 2.3.1 per oktober 2026), som følge av Ballot SC-081v3 (åpnes i en ny fane), vedtatt 11. april 2025:

Sertifikatet er utstedtMaksimal gyldighet
Før 15. mars 2026398 dager
15. mars 2026 til 14. mars 2027200 dager
15. mars 2027 til 14. mars 2029100 dager
Fra og med 15. mars 202947 dager

Kort levetid gjør manuell fornyelse risikabelt, så bekreft at webhotellet eller sertifikatverktøyet ditt fornyer automatisk. Bekreft også at vanlig HTTP omdirigeres til HTTPS:

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

Du vil ha et 301-svar (eller 308) med en location-header som starter med https://.

Hvilke sikkerhetsheadere bør en nettbutikk sende?

Et lite sett med svarheadere blokkerer vanlige angrep i nettleseren nesten uten kostnad.

HeaderHva den gjørTypisk verdiKilde
Strict-Transport-SecurityBer nettlesere om bare å bruke HTTPS og hindrer brukere i å klikke seg forbi sertifikatfeilmax-age=31536000; includeSubDomainsMDN (åpnes i en ny fane)
Content-Security-Policy: frame-ancestorsStyrer hvilke nettsteder som kan bygge inn sidene dine, noe som beskytter mot clickjackingframe-ancestors 'self'MDN (åpnes i en ny fane)
X-Frame-OptionsEldre kontroll av innramming; OWASP sier at frame-ancestors gjør den overflødig i nettlesere som støtter detDENY eller SAMEORIGINOWASP (åpnes i en ny fane)
X-Content-Type-OptionsStopper MIME-sniffing og blokkerer skript og stilark som serveres med feil typenosniffMDN (åpnes i en ny fane)
Referrer-PolicyBegrenser hvor mye av URL-ene dine som sendes til andre nettstederstrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader for nettleserens XSS-filter; OWASP sier at den kan skape XSS-sårbarheter på nettsteder som ellers er tryggeIkke sett den, eller bruk 0OWASP

Sjekk hva butikken din sender:

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

To ting å være obs på. includeSubDomains blokkerer alle underdomener som bare fungerer over HTTP, så sjekk underdomenene først. HSTS-forhåndslasting (preload) krever max-age på minst 31536000 og includeSubDomains, så legg bare til preload når alle underdomener er klare for HTTPS. En fullstendig CSP som begrenser skript, er verdt å ha, men OWASP påpeker at den er krevende å sette opp og vedlikeholde, og butikker med mange apper må teste den nøye.

Er informasjonskapslene dine satt med Secure, HttpOnly og SameSite?

Informasjonskapsler for økter og handlekurv bør ha alle tre attributtene, og du ser dem i Set-Cookie-headerne i svaret.

AttributtEffekt (ifølge MDN (åpnes i en ny fane))Hvor det er viktig
SecureSendes bare over HTTPS; nettsteder på vanlig HTTP kan ikke sette attributtetAlle informasjonskapsler i en HTTPS-butikk
HttpOnlyJavaScript kan ikke lese informasjonskapselen via document.cookie, noe som hjelper mot XSSInnloggingsøkter og handlekurver
SameSite=Lax eller StrictBegrenser når informasjonskapselen sendes ved forespørsler på tvers av nettstederØkter; Strict passer for informasjonskapsler for autentisering og handlekurv
SameSite=NoneSendes ved forespørsler på tvers av nettsteder; må kombineres med SecureBare innebygde tredjepartsfunksjoner som trenger det

Hvis ingen SameSite-attributt er satt, behandler nettlesere informasjonskapselen som Lax. Informasjonskapsler som dine egne skript må kunne lese, kan ikke være HttpOnly, så konsentrer deg om dem som identifiserer en innlogget kunde eller en administrator.

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

Utviklerverktøyene i nettleseren viser den samme informasjonen, inkludert informasjonskapsler som settes av skript etter at siden er lastet inn.

Hvordan finner du blandet innhold?

Blandet innhold (mixed content) er alle ressurser som lastes over HTTP på en side som serveres over HTTPS, og nettleserkonsollen viser dem.

MDN (åpnes i en ny fane) deler det inn i to grupper. Bilder, lyd og video kan «oppgraderes» (upgradable): Nettlesere ber automatisk om dem over HTTPS. Skript, stilark, iframes, skrifter og fetch()-forespørsler kan «blokkeres» (blockable): Nettlesere blokkerer dem, og det som var avhengig av dem, slutter å fungere. Oppgraderte forespørsler til en ren IP-adresse blokkeres også.

For å finne det åpner du konsollen på de viktigste malene (forside, kolleksjon, produkt, handlekurv) og søker etter http:// i temakoden, sideinnholdet og app-innstillingene. Shopifys hjelpesenter sier at alle butikksider med en ressurs som ikke leveres over HTTPS, regnes som usikre (åpnes i en ny fane), og anbefaler å lagre ressursene hos Shopify eller servere dem over HTTPS. I WooCommerce bør du sjekke gammelt innhold i innlegg og temaalternativer hvis nettstedet en gang kjørte på http://.

Hvordan oppdager du utdaterte JavaScript-biblioteker med kjente CVE-er?

List opp bibliotekene hver side laster inn, les versjonene og sammenlign dem med National Vulnerability Database (NVD).

Start med jQuery. I nettleserkonsollen returnerer $.fn.jquery versjonen som er lastet inn (jQuery API (åpnes i en ny fane)). Versjoner du bør flagge:

CVEBerørte versjonerProblemNVD-score (v3.1)
CVE-2020-11022 (åpnes i en ny fane)1.12.0 til før 3.5.0Hvis upålitelig HTML sendes til metoder som .html() eller .append(), kan kode bli kjørt6,1 (Medium)
CVE-2020-11023 (åpnes i en ny fane)1.0.3 til før 3.5.0Det samme, for HTML som inneholder <option>-elementer; i CISAs KEV-katalog siden 23. januar 20256,1 (Medium)
CVE-2019-11358 (åpnes i en ny fane)Før 3.4.0Prototype pollution via jQuery.extend(true, ...)6,1 (Medium)

Begge sårbarhetene fra 2020 er rettet i jQuery 3.5.0. En sårbar versjon betyr at den feilaktige koden er til stede. Om den kan utnyttes, avhenger av hvordan nettstedet sender data til den. WordPress har levert jQuery 3.5.1 siden versjon 5.6 (åpnes i en ny fane), så en gammel jQuery i en WooCommerce-butikk tyder på en utdatert WordPress-installasjon eller på et tema eller en utvidelse som laster sin egen kopi. I Shopify bør du sjekke temafilene og appene som legger inn skript.

Hva er security.txt, og trenger butikken din en?

Det er en ren tekstfil som forteller sikkerhetsforskere hvordan de kan melde fra til deg om en sårbarhet.

RFC 9116 (åpnes i en ny fane) (april 2022, en RFC av typen Informational, så det er frivillig å følge den) sier at filen må serveres over HTTPS på /.well-known/security.txt som text/plain. Contact og Expires er påkrevd, og RFC-en anbefaler en Expires-dato mindre enn ett år frem i tid.

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 legge filen på serveren din. På en driftet plattform må du sjekke om du kan publisere en fil på den stien. Hvis ikke, hjelper det likevel med en tydelig merket sikkerhetskontakt på kontaktsiden din.

Hvordan beskytter DMARC butikken din mot forfalsket e-post?

Med DMARC kan du be e-postleverandører om å sette i karantene eller avvise e-post som bruker domenet ditt i From-adressen uten å bestå samsvarende SPF eller DKIM.

En post med p=none samler bare inn rapporter; den stopper ikke forfalsket e-post. Kundene forventer ordrebekreftelser og e-post om tilbakestilling av passord fra domenet ditt, så en phishing-melding som viser nøyaktig ditt domene, er verdt å blokkere. Sjekk policyen din med dig +short TXT _dmarc.example.com, og se RFC 9989 (åpnes i en ny fane) for spesifikasjonen. DMARC dekker ikke domener som ligner på ditt, bare domenet som publiserer posten.

Hva administrerer Shopify, og hva styrer du selv i WooCommerce?

Shopify drifter serverne bak butikkfrontene sine, mens en egendriftet WooCommerce-butikk overlater serverinnstillingene til deg og webhotellet ditt.

KontrollShopifyWooCommerce (egendriftet)
TLS-sertifikatGratis for alle domener som er lagt til i Shopify (åpnes i en ny fane); kan ta opptil 48 timer for tredjepartsdomenerWebhotellet ditt eller ditt eget oppsett
Omdirigering fra HTTP til HTTPSPlattformenInnstillinger for webserver, CDN eller webhotell
SikkerhetsheadereSendes av Shopifys servereWebserver, CDN eller en utvidelse
Cookie-flaggShopifys egne informasjonskapsler settes av plattformen; informasjonskapsler fra apper og temaer er ditt ansvarWordPress-kjernen, utvidelser og serveren
Blandet innhold og JS-bibliotekerTemaet, innholdet og appene dineTemaet, innholdet og utvidelsene dine
security.txt og DMARCDomenet og DNS-en dinDomenet og DNS-en din

Da vi sjekket flere butikkfronter driftet av Shopify i oktober 2026, inneholdt svarene HSTS med en max-age på rundt 91 dager, X-Content-Type-Options: nosniff og en CSP med upgrade-insecure-requests, mens frame-ancestors varierte fra butikk til butikk. Shopify sier at selskapet er sertifisert som Level 1 PCI DSS-kompatibelt (åpnes i en ny fane). Temaet og appene du har installert, er fortsatt ditt ansvar.

For WooCommerce sier WordPress’ veiledning for herding (åpnes i en ny fane) at du bør holde WordPress og utvidelsene oppdatert, slette utvidelser du ikke bruker, og spørre webhotellet ditt hvilke sikkerhetstiltak de har.

Hvorfor er dette ikke en penetrasjonstest?

En penetrasjonstest prøver aktivt å gjennomføre angrep. Passive sjekker bare observerer.

NIST SP 800-115 definerer penetrasjonstesting som sikkerhetstesting der testerne etterligner reelle angrep for å finne måter å omgå sikkerhetsfunksjonene i et system på (NIST-ordlisten (åpnes i en ny fane)). Passive sjekker kan ikke se feil på serversiden i utvidelser, svake eller gjenbrukte administratorpassord, manglende tofaktorautentisering, svikt i tilgangskontrollen eller sårbar kode som aldri vises i kildekoden til siden. Bruk dem som et utgangspunkt du kan gjenta når som helst. For en grundigere vurdering bør du bestille en penetrasjonstest med skriftlig avgrensning, på systemer du eier eller har tillatelse til å teste.

En gratis skanning gjør en første gjennomgang av butikken din. Vår Sikkerhetsrapport for nettstedet dekker de passive sjekkene i denne artikkelen, fra TLS og omdirigeringer til headere, informasjonskapsler, blandet innhold, utdaterte biblioteker, security.txt og DMARC, med løsninger for hvert funn. Som enhver passiv gjennomgang kan den ikke garantere at en butikk er sikker.

Ofte stilte spørsmål

Setter passive sikkerhetssjekker butikken min i fare?

Ikke mer enn et vanlig besøk. De ber om de samme offentlige sidene og DNS-postene som en hvilken som helst nettleser eller e-postserver ville gjort, og de prøver ikke å logge inn eller sende angrepsdata.

Kan jeg legge til sikkerhetsheadere i Shopify?

Svarheaderne for butikkfronten kommer fra Shopifys servere, så kontakt Shopify Support hvis en header du trenger, mangler. En CSP-tagg av typen <meta> i temaet kan legge til noen direktiver, men MDN påpeker at frame-ancestors ikke støttes i <meta>.

Betyr en gammel jQuery-versjon at butikken min er hacket?

Nei. Det betyr at kode med kjente sårbarheter lastes inn, noe som øker risikoen hvis nettstedet sender upålitelig HTML til de berørte metodene. Oppdater jQuery, eller fjern temaet eller utvidelsen som laster den.

Hvor lenge kan et TLS-sertifikat være gyldig nå?

Offentlig klarerte sertifikater som er utstedt fra og med 15. mars 2026, kan maksimalt være gyldige i 200 dager. Grensen synker til 100 dager fra 15. mars 2027 og til 47 dager fra 15. mars 2029.

Er en security.txt-fil påkrevd?

RFC 9116 er en RFC av typen Informational, så etter standarden er det frivillig å publisere filen. Det koster lite å publisere den, og den gir forskere en tydelig måte å nå deg på.

Betyr en passiv skanning uten funn at butikken min er sikker?

Nei. Den viser at den offentlige konfigurasjonen ser riktig ut. Sårbarheter på serversiden, kontosikkerhet og feil i forretningslogikken krever andre typer testing.

Kilder

Alle veiledninger