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-ancestorsvirker 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 felterneContactogExpiresog 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 udstedt | Maksimal gyldighed |
|---|---|
| Før 15. marts 2026 | 398 dage |
| 15. marts 2026 til 14. marts 2027 | 200 dage |
| 15. marts 2027 til 14. marts 2029 | 100 dage |
| Fra 15. marts 2029 | 47 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.
| Header | Hvad den gør | Typisk værdi | Kilde |
|---|---|---|---|
Strict-Transport-Security | Beder browsere om kun at bruge HTTPS og forhindrer brugere i at klikke sig forbi certifikatfejl | max-age=31536000; includeSubDomains | MDN (åbner i en ny fane) |
Content-Security-Policy: frame-ancestors | Styrer, hvilke sites der må indlejre dine sider, og beskytter dermed mod clickjacking | frame-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 det | DENY eller SAMEORIGIN | OWASP (åbner i en ny fane) |
X-Content-Type-Options | Stopper MIME-sniffing og blokerer scripts og stylesheets, der leveres med forkert type | nosniff | MDN (åbner i en ny fane) |
Referrer-Policy | Begrænser, hvor meget af dine URL’er der sendes videre til andre sites | strict-origin-when-cross-origin | OWASP |
X-XSS-Protection | Header til browserens XSS-filter; ifølge OWASP kan den skabe XSS-sårbarheder på sites, der ellers er sikre | Undlad den, eller brug 0 | OWASP |
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.
| Attribut | Effekt (ifølge MDN (åbner i en ny fane)) | Hvor det er vigtigt |
|---|---|---|
Secure | Sendes kun over HTTPS; sites på almindelig HTTP kan ikke sætte den | Alle cookies i en webshop på HTTPS |
HttpOnly | JavaScript kan ikke læse den via document.cookie, hvilket hjælper mod XSS | Login-sessioner og kurve |
SameSite=Lax eller Strict | Begrænser, hvornår cookien sendes med forespørgsler på tværs af sites | Sessioner; Strict passer til cookies for login og kurv |
SameSite=None | Sendes med forespørgsler på tværs af sites; skal kombineres med Secure | Kun 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å:
| CVE | Berørte versioner | Problem | NVD-score (v3.1) |
|---|---|---|---|
| CVE-2020-11022 (åbner i en ny fane) | 1.12.0 til før 3.5.0 | Hvis ikke-betroet HTML sendes til metoder som .html() eller .append(), kan der blive afviklet kode | 6,1 Medium |
| CVE-2020-11023 (åbner i en ny fane) | 1.0.3 til før 3.5.0 | Det samme for HTML, der indeholder <option>-elementer; i CISA’s KEV-katalog siden 23. januar 2025 | 6,1 Medium |
| CVE-2019-11358 (åbner i en ny fane) | Før 3.4.0 | Prototype 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.
| Tjek | Shopify | WooCommerce (selvhostet) |
|---|---|---|
| TLS-certifikat | Gratis for alle domæner, der er tilføjet til Shopify (åbner i en ny fane); kan tage op til 48 timer for tredjepartsdomæner | Din host eller din egen opsætning |
| Omdirigering fra HTTP til HTTPS | Platformen | Indstillinger på webserver, CDN eller hos din host |
| Sikkerhedsheadere | Sendes af Shopifys servere | Webserver, CDN eller et plugin |
| Cookie-flag | Shopifys egne cookies sættes af platformen; cookies fra apps og tema er dit ansvar | WordPress-kernen, plugins og serveren |
| Blandet indhold og JS-biblioteker | Dit tema, dit indhold og dine apps | Dit tema, dit indhold og dine plugins |
| security.txt og DMARC | Dit domæne og din DNS | Dit 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
- Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (åbner i en ny fane), CA/Browser Forum, 4. oktober 2026
- Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (åbner i en ny fane), CA/Browser Forum, 11. april 2025
- Strict-Transport-Security (åbner i en ny fane), MDN Web Docs, senest ændret 11. september 2026
- CSP: frame-ancestors (åbner i en ny fane), MDN Web Docs, senest ændret 27. august 2026
- X-Content-Type-Options (åbner i en ny fane), MDN Web Docs, senest ændret 17. marts 2026
- Using HTTP cookies (åbner i en ny fane), MDN Web Docs, senest ændret 17. september 2026
- Mixed content (åbner i en ny fane), MDN Web Docs, senest ændret 15. august 2026
- HTTP Security Response Headers Cheat Sheet (åbner i en ny fane), OWASP Cheat Sheet Series, tilgået 22. oktober 2026
- CVE-2020-11022 (åbner i en ny fane), NIST National Vulnerability Database, offentliggjort 29. april 2020
- CVE-2020-11023 (åbner i en ny fane), NIST National Vulnerability Database, offentliggjort 29. april 2020
- CVE-2019-11358 (åbner i en ny fane), NIST National Vulnerability Database, offentliggjort 20. april 2019
- .jquery (åbner i en ny fane), jQuery API Documentation, tilgået 22. oktober 2026
- Updating core jQuery to version 3, part 2 (åbner i en ny fane), Make WordPress Core, 5. november 2020
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (åbner i en ny fane), IETF, april 2022
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (åbner i en ny fane), IETF, maj 2026
- Enabling secure connections to your Shopify store (åbner i en ny fane), Shopify Help Center, tilgået 22. oktober 2026
- Security (åbner i en ny fane), Shopify, tilgået 22. oktober 2026
- Hardening WordPress (åbner i en ny fane), WordPress Developer Resources, tilgået 22. oktober 2026
- Penetration testing (glossary) (åbner i en ny fane), NIST Computer Security Resource Center, med henvisning til NIST SP 800-115 (september 2008), tilgået 22. oktober 2026
Alle guides
- Core Web Vitals for webshops: LCP, INP og CLS forklaretHvad LCP, INP og CLS måler, grænserne for god og dårlig ved 75. percentil, labdata vs. feltdata og de typiske rettelser i Shopify- og WooCommerce-webshops.
- European Accessibility Act og webshops: det gælder fra juni 2025Siden 28. juni 2025 gælder tilgængelighedsdirektivet (EAA) for webshops med EU-kunder: hvem er omfattet, mikrovirksomheder, EN 301 549, WCAG og oplysningskrav.
- Fået et ADA-kravbrev om din hjemmeside? Det skal du tjekke førstHvad ADA-kravbreve påstår, WCAG’s rolle, hvad du skal samle, hvorfor overlays ikke retter koden, og hvornår du skal have advokat. Ikke juridisk rådgivning.