Sikkerhedstjek af hjemmeside og webshop uden at hacke noget

Passive sikkerhedstjek til webshops: udløb af TLS-certifikat, HSTS, CSP, nosniff, cookie-flag, blandet indhold, forældet jQuery, security.txt og DMARC.

FixReports’ redaktion10 min. læsetid

Du kan tjekke en stor del af en webshops sikkerhedsopsætning udefra ved at læse det, sitet allerede sender til alle besøgende: TLS-certifikatet, omdirigeringer, HTTP-svarheadere, cookies, de scripts, siden indlæser, og de offentlige DNS-poster. Disse passive tjek sender ingen angrebstrafik og kræver intet login, så de belaster ikke en webshop mere end et almindeligt besøg. De fanger huller i konfigurationen som et certifikat, der snart udløber, manglende HSTS, usikre cookies, blandet indhold (mixed content) eller en jQuery-version med kendte sårbarheder. De er ikke en penetrationstest og kan ikke bevise, at en webshop er sikker.

Det vigtigste kort fortalt

  • Offentligt betroede TLS-certifikater, der er udstedt siden 15. marts 2026, må højst være gyldige i 200 dage, og grænsen falder til 100 dage i marts 2027 og 47 dage i marts 2029 (CA/Browser Forum (åbner i en ny fane)).
  • Browsere ignorerer HSTS-headeren, når den sendes over almindelig HTTP (MDN (åbner i en ny fane)).
  • CSP-direktivet frame-ancestors virker ikke i et <meta>-tag; det skal sendes som en svarheader (MDN (åbner i en ny fane)).
  • jQuery-versioner før 3.5.0 er ramt af to XSS-sårbarheder, og CISA føjede den ene af dem, CVE-2020-11023, til sit katalog over kendte udnyttede sårbarheder (Known Exploited Vulnerabilities) den 23. januar 2025 (NVD (åbner i en ny fane)).
  • En security.txt-fil skal indeholde felterne Contact og Expires og ligge på /.well-known/security.txt (RFC 9116 (åbner i en ny fane)).

Hvad tæller som et passivt sikkerhedstjek?

Et passivt tjek læser kun det, sitet eller dets DNS returnerer på en almindelig forespørgsel.

Det betyder at indlæse offentlige sider, læse certifikatet og svarheaderne, liste de cookies og scripts, en side sætter, og slå offentlige DNS-poster op. Et passivt tjek gætter ikke adgangskoder, sender ikke injection-payloads, afprøver ikke admin-URL’er og scanner ikke porte. Alt nedenfor kan gøres med en browser, curl, openssl og dig.

Hvordan tjekker du dit TLS-certifikat, og hvornår det udløber?

Aflæs certifikatets datoer og navne direkte, og sørg for, at fornyelsen er automatiseret.

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

Tjek, at notAfter ligger et godt stykke ude i fremtiden, at certifikatet dækker både example.com og www.example.com, hvis du bruger begge (browserens certifikatviser viser navnene), og at browseren ikke viser advarsler. Certifikaternes levetid bliver kortere efter CA/Browser Forums Baseline Requirements (afsnit 6.3.2, version 2.3.1 pr. oktober 2026) som følge af Ballot SC-081v3 (åbner i en ny fane), der blev vedtaget den 11. april 2025:

Certifikat udstedtMaksimal gyldighed
Før 15. marts 2026398 dage
15. marts 2026 til 14. marts 2027200 dage
15. marts 2027 til 14. marts 2029100 dage
Fra 15. marts 202947 dage

Korte levetider gør manuel fornyelse risikabel, så bekræft, at din host eller dit certifikatværktøj fornyer automatisk. Bekræft også, at almindelig HTTP omdirigerer til HTTPS:

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

Du vil gerne se et 301-svar (eller 308) med en location-header, der starter med https://.

Hvilke sikkerhedsheadere bør en webshop sende?

Et lille sæt svarheadere blokerer almindelige angreb i browseren næsten uden omkostninger.

HeaderHvad den gørTypisk værdiKilde
Strict-Transport-SecurityBeder browsere om kun at bruge HTTPS og forhindrer brugere i at klikke sig forbi certifikatfejlmax-age=31536000; includeSubDomainsMDN (åbner i en ny fane)
Content-Security-Policy: frame-ancestorsStyrer, hvilke sites der må indlejre dine sider, og beskytter dermed mod clickjackingframe-ancestors 'self'MDN (åbner i en ny fane)
X-Frame-OptionsÆldre styring af indramning; ifølge OWASP gør frame-ancestors den overflødig i browsere, der understøtter detDENY eller SAMEORIGINOWASP (åbner i en ny fane)
X-Content-Type-OptionsStopper MIME-sniffing og blokerer scripts og stylesheets, der leveres med forkert typenosniffMDN (åbner i en ny fane)
Referrer-PolicyBegrænser, hvor meget af dine URL’er der sendes videre til andre sitesstrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader til browserens XSS-filter; ifølge OWASP kan den skabe XSS-sårbarheder på sites, der ellers er sikreUndlad den, eller brug 0OWASP

Tjek, hvad din webshop 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 forbehold. includeSubDomains blokerer alle underdomæner, der kun virker over HTTP, så tjek underdomænerne først. HSTS-preloading kræver en max-age på mindst 31536000 og includeSubDomains, så tilføj kun preload, når alle underdomæner er klar til HTTPS. En fuld CSP, der begrænser scripts, er værd at have, men OWASP påpeger, at den er kompleks at konfigurere og vedligeholde, og webshops med mange apps skal teste den omhyggeligt.

Er dine cookies sat med Secure, HttpOnly og SameSite?

Session- og kurvcookies bør have alle tre attributter, og du kan se dem i svarheaderne Set-Cookie.

AttributEffekt (ifølge MDN (åbner i en ny fane))Hvor det er vigtigt
SecureSendes kun over HTTPS; sites på almindelig HTTP kan ikke sætte denAlle cookies i en webshop på HTTPS
HttpOnlyJavaScript kan ikke læse den via document.cookie, hvilket hjælper mod XSSLogin-sessioner og kurve
SameSite=Lax eller StrictBegrænser, hvornår cookien sendes med forespørgsler på tværs af sitesSessioner; Strict passer til cookies for login og kurv
SameSite=NoneSendes med forespørgsler på tværs af sites; skal kombineres med SecureKun indlejrede tredjepartsfunktioner, der har brug for det

Hvis der ikke er sat nogen SameSite-attribut, behandler browsere cookien som Lax. Cookies, som dine egne scripts skal kunne læse, kan ikke være HttpOnly, så fokuser på dem, der identificerer en kunde eller en administrator, der er logget ind.

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

Browserens udviklerværktøjer viser de samme oplysninger, også de cookies, som scripts sætter, efter at siden er indlæst.

Hvordan finder du blandet indhold?

Blandet indhold (mixed content) er enhver ressource, der indlæses over HTTP på en side, der leveres over HTTPS, og browserkonsollen viser det.

MDN (åbner i en ny fane) deler det i to grupper. Billeder, lyd og video kan »opgraderes« (upgradable): browsere anmoder automatisk om dem over HTTPS. Scripts, stylesheets, iframes, skrifttyper og fetch()-forespørgsler kan »blokeres« (blockable): browsere blokerer dem, hvilket ødelægger det, der afhang af dem. Opgraderede forespørgsler til en ren IP-adresse blokeres også.

For at finde det skal du åbne konsollen på dine vigtigste skabeloner (forside, kollektion, produkt, kurv) og søge efter http:// i din temakode, dit sideindhold og dine app-indstillinger. Ifølge Shopifys hjælpecenter betragtes en butiksside som usikker (åbner i en ny fane), hvis den har en ressource, der ikke leveres over HTTPS, og Shopify anbefaler at hoste ressourcer hos Shopify eller levere dem over HTTPS. I WooCommerce skal du tjekke ældre indhold i indlæg og temaindstillinger, hvis sitet nogensinde har kørt på http://.

Hvordan opdager du forældede JavaScript-biblioteker med kendte CVE’er?

Lav en liste over de biblioteker, hver side indlæser, aflæs deres versioner, og sammenlign dem med National Vulnerability Database.

Start med jQuery. I browserkonsollen returnerer $.fn.jquery den indlæste version (jQuery API (åbner i en ny fane)). Versioner, du skal være opmærksom på:

CVEBerørte versionerProblemNVD-score (v3.1)
CVE-2020-11022 (åbner i en ny fane)1.12.0 til før 3.5.0Hvis ikke-betroet HTML sendes til metoder som .html() eller .append(), kan der blive afviklet kode6,1 Medium
CVE-2020-11023 (åbner i en ny fane)1.0.3 til før 3.5.0Det samme for HTML, der indeholder <option>-elementer; i CISA’s KEV-katalog siden 23. januar 20256,1 Medium
CVE-2019-11358 (åbner i en ny fane)Før 3.4.0Prototype pollution via jQuery.extend(true, ...)6,1 Medium

Begge problemer fra 2020 er rettet i jQuery 3.5.0. En sårbar version betyder, at den fejlbehæftede kode er til stede; om den kan udnyttes, afhænger af, hvordan sitet sender data til den. WordPress har leveret jQuery 3.5.1 siden version 5.6 (åbner i en ny fane), så en gammel jQuery i en WooCommerce-butik peger på en forældet WordPress eller på et tema eller plugin, der indlæser sin egen kopi. I Shopify skal du tjekke dine temafiler og de apps, der indsætter scripts.

Hvad er security.txt, og har din webshop brug for en?

Det er en almindelig tekstfil, der fortæller sikkerhedsforskere, hvordan de kan rapportere en sårbarhed til dig.

RFC 9116 (åbner i en ny fane) (april 2022, en Informational RFC, så det er frivilligt at følge den) siger, at filen skal leveres over HTTPS på /.well-known/security.txt som text/plain. Contact og Expires er påkrævet, og RFC’en anbefaler en Expires-dato, der ligger mindre end et år ude i fremtiden.

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ægge filen på din server. På en hostet platform skal du tjekke, om du kan publicere en fil på den sti; hvis ikke, hjælper en tydeligt markeret sikkerhedskontakt på din kontaktside stadig.

Hvordan beskytter DMARC din webshop mod e-mailspoofing?

Med DMARC kan du bede postkasseudbydere om at sætte e-mails i karantæne eller afvise dem, hvis de bruger dit domæne i From-adressen uden at bestå afstemt (aligned) SPF eller DKIM.

En post med p=none indsamler kun rapporter; den stopper ikke forfalskede e-mails. Kunderne forventer ordrebekræftelser og nulstilling af adgangskoder fra dit domæne, så en phishingmail, der viser præcis dit domæne, er værd at blokere. Tjek din politik med dig +short TXT _dmarc.example.com, og se RFC 9989 (åbner i en ny fane) for specifikationen. DMARC dækker ikke domæner, der ligner dit, kun det domæne, der publicerer posten.

Hvad styrer Shopify, og hvad styrer du selv i WooCommerce?

Shopify driver serverne bag sine butiksfronter, mens en selvhostet WooCommerce-butik overlader serverindstillingerne til dig og din host.

TjekShopifyWooCommerce (selvhostet)
TLS-certifikatGratis for alle domæner, der er tilføjet til Shopify (åbner i en ny fane); kan tage op til 48 timer for tredjepartsdomænerDin host eller din egen opsætning
Omdirigering fra HTTP til HTTPSPlatformenIndstillinger på webserver, CDN eller hos din host
SikkerhedsheadereSendes af Shopifys servereWebserver, CDN eller et plugin
Cookie-flagShopifys egne cookies sættes af platformen; cookies fra apps og tema er dit ansvarWordPress-kernen, plugins og serveren
Blandet indhold og JS-bibliotekerDit tema, dit indhold og dine appsDit tema, dit indhold og dine plugins
security.txt og DMARCDit domæne og din DNSDit domæne og din DNS

Da vi tjekkede flere butiksfronter hostet hos Shopify i oktober 2026, indeholdt deres svar HSTS med en max-age på omkring 91 dage, X-Content-Type-Options: nosniff og en CSP med upgrade-insecure-requests, mens frame-ancestors varierede fra butik til butik. Shopify oplyser, at virksomheden er certificeret som PCI DSS-kompatibel på niveau 1 (åbner i en ny fane). Dit tema og dine installerede apps er stadig dit ansvar.

I WooCommerce siger WordPress’ vejledning i hærdning (åbner i en ny fane), at du skal holde WordPress og plugins opdateret, slette plugins, du ikke bruger, og spørge din host, hvilke sikkerhedsforanstaltninger de har.

Hvorfor er dette ikke en penetrationstest?

En penetrationstest forsøger aktivt at angribe; passive tjek observerer kun.

NIST SP 800-115 definerer penetrationstest som sikkerhedstest, hvor evaluatorer efterligner virkelige angreb for at finde måder at omgå et systems sikkerhedsfunktioner på (NIST’s ordliste (åbner i en ny fane)). Passive tjek kan ikke se fejl på serversiden i plugins, svage eller genbrugte adgangskoder til administration, manglende totrinsgodkendelse, mangelfuld adgangskontrol eller sårbar kode, der aldrig optræder i sidens kildekode. Brug dem som et udgangspunkt, du kan gentage når som helst. Hvis du vil have større sikkerhed for, at alt er i orden, så bestil en penetrationstest med et skriftligt afgrænset omfang på systemer, du ejer eller har tilladelse til at teste.

En gratis scanning laver en første gennemgang af din webshop. Vores Sikkerhedsrapport for hjemmesiden dækker de passive tjek i denne artikel, fra TLS og omdirigeringer til headere, cookies, blandet indhold, forældede biblioteker, security.txt og DMARC, med rettelser til hvert fund. Som enhver passiv gennemgang kan den ikke garantere, at en webshop er sikker.

Ofte stillede spørgsmål

Udsætter passive sikkerhedstjek min webshop for risiko?

Ikke mere end et almindeligt besøg. De anmoder om de samme offentlige sider og DNS-poster, som enhver browser eller mailserver ville gøre, og de forsøger ikke at logge ind eller sende angrebs-payloads.

Kan jeg tilføje sikkerhedsheadere i Shopify?

Svarheaderne for butiksfronten kommer fra Shopifys servere, så kontakt Shopify Support, hvis der mangler en header, du har brug for. Et CSP-<meta>-tag i dit tema kan tilføje nogle direktiver, men MDN påpeger, at frame-ancestors ikke understøttes i <meta>.

Betyder en gammel jQuery-version, at min webshop er blevet hacket?

Nej. Det betyder, at der indlæses kode med kendte sårbarheder, hvilket øger risikoen, hvis sitet sender ikke-betroet HTML til de berørte metoder. Opdater den, eller fjern det tema eller plugin, der indlæser den.

Hvor længe må et TLS-certifikat være gyldigt nu?

Offentligt betroede certifikater, der er udstedt fra 15. marts 2026, må højst være gyldige i 200 dage. Grænsen falder til 100 dage fra 15. marts 2027 og til 47 dage fra 15. marts 2029.

Er en security.txt-fil påkrævet?

RFC 9116 er en Informational RFC, så det er frivilligt efter standarden at publicere filen. Den er billig at publicere og giver forskere en tydelig måde at kontakte dig på.

Betyder en ren passiv scanning, at min webshop er sikker?

Nej. Den viser, at den offentlige konfiguration ser rigtig ud. Sårbarheder på serversiden, kontosikkerhed og fejl i forretningslogikken kræver andre former for test.

Kilder