Gå til innholdet
ipaddress.no

Sjekk sikkerhetsheadere

Vi henter svarheaderne til en offentlig URL (uten innhold) og sjekker de beskyttende headerne én for én.

Eksempler:

Noen av de mest effektive beskyttelsene på nettet er vanlige HTTP-svarheadere, satt én gang på serveren. Sjekken henter svarheaderne til en offentlig URL, følger videresendinger til den endelige siden og sjekker dem én for én:

  • Strict-Transport-Security får nettlesere til å bruke bare HTTPS.
  • Content-Security-Policy begrenser hvor skript og andre ressurser kan lastes fra, og med frame-ancestors hvem som kan bygge inn siden.
  • X-Content-Type-Options: nosniff hindrer nettlesere i å gjette filtyper.
  • Referrer-Policy styrer hvor mye av URL-en som sendes videre til andre nettsteder.
  • Permissions-Policy slår av nettleserfunksjoner nettstedet ikke bruker.
  • Cross-Origin-Opener-Policy isolerer siden fra vinduer den åpner.

Den markerer også programvareversjoner som oppgis i Server eller X-Powered-By. Resultatet er en sjekkliste, ikke en sikkerhetskarakter: headere er ett lag blant mange.

Ofte stilte spørsmål

Hvorfor merkes HSTS under seks måneder som svak?

Nettlesere husker HTTPS-kravet bare i max-age sekunder. Seks måneder til ett år er den vanlige anbefalingen, og kreves for nettlesernes preload-lister.

Trengs X-Frame-Options fortsatt?

CSP-direktivet frame-ancestors erstatter den i moderne nettlesere. Begge teller som rammebeskyttelse her.

Sender verktøyet noe annet enn en vanlig forespørsel?

Nei. Det sender én vanlig GET-forespørsel per videresending, leser bare headerne og lukker forbindelsen.

Relatert