Sådan konfigureres sikkerhedsheadere i Nginx

Sidst opdateret den 25. juli 2024 kl. 15.28 af Joshua James
Estimeret læsetid: 16 minutter
Konfiguration af sikkerhedsheadere i Nginx

Konfiguration af sikkerhedsheadere i NGINX er afgørende for at forbedre sikkerheden i dine webapplikationer. Sikkerhedsheadere beskytter mod forskellige angreb, såsom cross-site scripting (XSS), clickjacking og andre kodeinjektionsangreb. De instruerer browseren i, hvordan man håndterer dit websteds indhold, hvilket giver et ekstra lag af sikkerhed.

Denne guide vil lede dig gennem trinene til at konfigurere sikkerhedsheadere i NGINX, og hjælper dig med at beskytte dine webapplikationer og forbedre den overordnede sikkerhed.

Implementering af HTTP Strict Transport Security (HSTS) i NGINX

Forståelse af HSTS

HTTP Strict Transport Security (HSTS) er en vigtig webstedssikkerhedsprotokol. Det håndhæver, at forbindelser til et domæne udelukkende er over HTTPS. Dette mindsker risici som man-in-the-middle-angreb og sikrer integriteten og fortroligheden af ​​data, der transmitteres online. Når en bruger forsøger at få adgang til et websted via HTTP, opgraderer HSTS automatisk forbindelsen til HTTPS.

Konfiguration af HSTS i NGINX

For at opsætte HSTS i NGINX skal du opdatere serverblokken i NGINX-konfigurationsfilen. Denne fil ligger typisk på /etc/nginx/nginx.conf eller i stedspecifikke konfigurationer på /etc/nginx/sites-available/. Opdateringen involverer tilføjelse af en header, der instruerer browseren om altid at bruge HTTPS for det angivne domæne.

Tilføj følgende linje i serverblokken for dit domæne:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Denne linje indeholder to komponenter:

  • max-age=31536000: Instruer browseren om at huske at bruge HTTPS til dit websted i de næste 12 måneder.
  • includeSubDomains: Anvender HSTS-politikken på alle underdomæner på dit websted for omfattende sikkerhed.

Eksempel på NGINX-konfiguration med HSTS

Din NGINX-konfiguration med HSTS-headeren kan se sådan ud:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        proxy_pass http://my_portal;
    }
}

Efter tilføjelse af denne header, genindlæs NGINX for at gennemføre ændringerne med sudo systemctl reload nginx eller sudo nginx -s reload.

Yderligere NGINX-konfigurationseksempler

For forskellige scenarier kan din NGINX-konfiguration med HSTS variere. Her er yderligere eksempler:

Multi-domæne server

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Denne konfiguration anvender HSTS til flere domæner, der hostes på den samme server. Hvert domæne på listen vil håndhæve HTTPS-forbindelser.

Server med SSL-terminering

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Denne opsætning er til servere, der håndterer SSL-afslutning. Den konfigurerer HSTS på en sikker port (443) med specificerede SSL-certifikater, hvilket forstærker sikre forbindelser.

Konfiguration af Content-Security-Policy (CSP) i NGINX

Implementering af CSP i NGINX

At integrere en Content-Security-Policy (CSP) i NGINX er et strategisk træk for at forbedre webapplikationssikkerheden. Det involverer tilføjelse af en specifik header i serverblokken i din NGINX-konfigurationsfil. Denne fil findes typisk på /etc/nginx/nginx.conf eller i mappen /etc/nginx/sites-available/, og denne fil kræver omhyggelig redigering for at anvende CSP effektivt.

For en grundlæggende CSP-opsætning skal du tilføje følgende linje i serverblokken:

add_header Content-Security-Policy "default-src 'self';" always;

Dette direktiv begrænser indlæsning af indhold til webstedets domæne ("selv"), hvilket i væsentlig grad reducerer risikoen for ondsindet eksternt indholdsudførelse.

Eksempel på NGINX-konfiguration med CSP

Din NGINX-konfiguration med det grundlæggende CSP-direktiv kan se sådan ud:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Content-Security-Policy "default-src 'self';" always;

    location / {
        proxy_pass http://my_portal;
    }
}

Genindlæs NGINX med sudo systemctl genindlæs nginx eller sudo nginx -s genindlæs efter tilføjelse af dette direktiv.

Tilpasning af CSP til specifikke behov

CSP kan skræddersyes til at imødekomme specifikke sikkerhedsbehov på din hjemmeside. Her er udvidede konfigurationer til forskellige scenarier:

Tillad billeder fra enhver kilde

add_header Content-Security-Policy "default-src 'self'; img-src *;" always;

Denne konfiguration tillader indlæsning af billeder fra enhver kilde og opretholder streng kontrol over andre typer indhold.

Konfiguration af specifikke scripts og stilarter

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscript.com; style-src 'self' 'unsafe-inline';";

Denne indstilling tillader scripts fra dit domæne og en betroet ekstern kilde sammen med inline-stile, hvilket balancerer funktionalitet med sikkerhed.

Udforskning af CSP-direktiver og -muligheder

Direktiver i CSP

CSP-direktiver er regler, der definerer politikken for specifikke indholdstyper. Fælles direktiver omfatter:

  • default-src: Standardpolitikken, der anvendes på de fleste indholdstyper.
  • script-src: Styrer kilderne til JavaScript-ressourcer.
  • style-src: Specificerer tilladte kilder til CSS-ressourcer.
  • img-src: Styrer kilderne til billedressourcer.
  • connect-src: Indstiller politikker for netværksforbindelser som XMLHttpRequest, WebSocket og EventSource.

Kildeudtryk i CSP

Kildeudtryk definerer tilladte kilder for hvert direktiv:

  • 'ingen': Blokerer alle kilder.
  • 'selv': Tillader ressourcer fra samme oprindelse.
  • 'unsafe-inline': Tillader inline-ressourcer såsom typografier eller JavaScript-URL'er.
  • 'unsafe-eval': Tillader JavaScript eval() funktioner og lignende metoder.
  • https:: Aktiverer ressourcer fra enhver HTTPS-URL.

Konfiguration af X-XSS-Protection i NGINX

Introduktion til X-XSS-Protection

X-XSS-Protection eller Cross-Site Scripting-headeren er afgørende for at beskytte webapplikationer mod XSS (Cross-Site Scripting)-angreb. Understøttet af store webbrowsere som Chrome, Internet Explorer og Safari forbedrer denne header websikkerheden ved at forhindre indlæsning af sider, når reflekterede XSS-angreb detekteres.

Aktivering af X-XSS-beskyttelse i NGINX

Integrering af X-XSS-Protection-headeren i din NGINX-serverkonfiguration styrker browserens native XSS-beskyttelse. For at aktivere denne sikkerhedsfunktion skal du få adgang til din NGINX-konfigurationsfil, typisk placeret på /etc/nginx/nginx.conf eller i mappen /etc/nginx/sites-available/.

Indsæt dette direktiv i serverblokken i din NGINX-konfigurationsfil:

add_header X-XSS-Protection "1; mode=block";

Dette direktiv består af to dele:

  • 1: Aktiverer browserens XSS-filter.
  • mode=blok: Dirigerer browseren til at blokere siden, hvis der opdages et XSS-angreb, i stedet for at forsøge at rense den.

Eksempel på NGINX-konfiguration med X-XSS-beskyttelse

Et eksempel på NGINX-konfiguration inklusive X-XSS-beskyttelse kan se ud som følger:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://my_portal;
    }
}

Efter tilføjelse af denne header, genindlæs NGINX ved at bruge enten sudo systemctl reload nginx eller sudo nginx -s reload.

Yderligere NGINX-konfigurationsscenarier

Til en server med SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Denne opsætning er til servere med SSL, hvilket sikrer, at X-XSS-Protection er aktiv på krypterede forbindelser.

Håndtering af flere domæner

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Denne konfiguration anvender X-XSS-beskyttelse på tværs af flere domæner, der hostes på en enkelt server.

Konfiguration af X-Frame-Options i NGINX

Rollen af ​​X-Frame-Options

X-Frame-Options er en vigtig sikkerhedsheader designet til at beskytte websteder mod clickjacking-angreb. Det forhindrer websider i at blive vist i frames eller iframes, som ofte bruges i disse angreb. Understøttet af alle større webbrowsere giver X-Frame-Options udbredt beskyttelse, hvilket øger sikkerheden for din webtilstedeværelse på tværs af forskellige platforme.

Implementering af X-Frame-Options i NGINX

Inkorporering af X-Frame-Options-headeren i din NGINX-serverkonfiguration er afgørende for at forbedre dit websteds sikkerhed. Denne opgave involverer redigering af NGINX-konfigurationsfilen, som typisk findes på /etc/nginx/nginx.conf eller i mappen /etc/nginx/sites-available/.

For at aktivere denne sikkerhedsfunktion skal du tilføje følgende direktiv til serverblokken i din NGINX-konfigurationsfil:

add_header X-Frame-Options "DENY";

Dette direktiv, sat til "NEDT", instruerer browseren i at blokere ethvert forsøg på at gengive siden i en frame eller iframe, hvilket tilbyder et robust forsvar mod clickjacking.

Eksempel på NGINX-konfiguration med X-Frame-Options

Et eksempel på NGINX-opsætning med X-Frame-Options-headeren er som følger:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Frame-Options "DENY";

    location / {
        proxy_pass http://my_portal;
    }
}

Når du har tilføjet denne overskrift, er det vigtigt at genindlæse NGINX for at aktivere ændringerne. Dette kan gøres ved at bruge sudo systemctl reload nginx eller sudo nginx -s reload.

Udvidelse af NGINX-konfiguration til X-Frame-Options

Til SSL-aktiverede servere

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Denne konfiguration er til servere med SSL, hvilket sikrer, at X-Frame-Options håndhæves på sikre forbindelser.

Håndtering af flere domæner

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Denne opsætning anvender X-Frame-Options-headeren på tværs af flere domæner på den samme server, hvilket styrker sikkerheden for hvert domæne.

Implementering af X-Content-Type-Options i NGINX

Rolle af X-Content-Type-Options

X-Content-Type-Options er en vigtig sikkerhedsheader inden for websikkerhed, der forhindrer browsere i at sniffning af MIME-typen. Denne header forstærker, at browsere respekterer den erklærede indholdstype i HTTP-headere, og adresserer sikkerhedssårbarheder, der kan opstå, når browsere fejlfortolker filtyper, såsom at behandle billedfiler som eksekverbar HTML, hvilket kan føre til cross-site scripting (XSS) angreb.

Opsætning af X-Content-Type-Options i NGINX

For at forbedre din webservers sikkerhed med X-Content-Type-Options-headeren skal du ændre NGINX-konfigurationsfilen ligetil. Denne fil findes normalt på /etc/nginx/nginx.conf eller i webstedsspecifikke konfigurationer i /etc/nginx/sites-available/.

Inkorporer denne overskrift ved at tilføje følgende linje til server blok af din NGINX-konfiguration:

add_header X-Content-Type-Options "nosniff";

Indstillingen "nosniff" instruerer browseren til strengt at følge serverens specificerede indholdstype, hvilket forhindrer alternative fortolkninger af indholdet.

Eksempel på NGINX-konfiguration med X-Content-Type-Options

En NGINX-konfiguration med X-Content-Type-Options kan være struktureret som følger:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://my_portal;
    }
}

Efter opdatering af din konfiguration skal du sørge for at genindlæse NGINX for at ændringerne træder i kraft, ved at bruge sudo systemctl reload nginx eller sudo nginx -s reload.

Eksempler på udvidede NGINX-konfigurationer

Konfiguration til SSL/TLS

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header X-Content-Type-Options "nosniff";

    # Additional SSL configurations and locations
}

Denne opsætning er til servere med SSL/TLS, der anvender X-Content-Type-Options på sikre forbindelser for at øge sikkerheden.

Multi-Domain Server Konfiguration

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Content-Type-Options "nosniff";

    # Additional configurations for multiple domains
}

Denne konfiguration anvender X-Content-Type-Options-headeren på tværs af flere domæner, der hostes på den samme server, hvilket sikrer ensartede sikkerhedsindstillinger på tværs af alle domæner.

Konfiguration af Referrer-Policy i NGINX

Funktionen af ​​henvisningspolitik

Referrer-Policy er en vigtig HTTP-header til at forbedre brugernes privatliv og sikkerhed på nettet. Det styrer, hvor mange henvisningsoplysninger der er inkluderet i Referer-headeren, når brugere navigerer fra dit websted til andre, og beskytter følsomme oplysninger mod eksponering i webanmodninger.

Opsætning af Referrer-Policy i NGINX

For at implementere Referrer-Policy-headeren i din NGINX-server skal du ændre NGINX-konfigurationsfilen, som typisk findes på /etc/nginx/nginx.conf eller i mappen /etc/nginx/sites-available/. Tilføj følgende direktiv til serverblokken:

add_header Referrer-Policy "no-referrer";

Dette direktiv, sat til "no-referrer", sikrer, at ingen henvisningsoplysninger sendes under webstedsnavigation, hvilket maksimerer privatlivets fred.

Eksempel på NGINX-konfiguration med henvisningspolitik

Din NGINX-konfiguration med Referrer-Policy-headeren kunne se sådan ud:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Referrer-Policy "no-referrer";

    location / {
        proxy_pass http://my_portal;
    }
}

Efter tilføjelse af denne header, genindlæs NGINX med kommandoer som sudo systemctl reload nginx eller sudo nginx -s reload.

Henvisningspolitik-indstillinger og definitioner

  • no-referrer: Der sendes ingen henvisningsoplysninger.
  • no-referrer-when-downgrade (standard): Sender henvisningsoplysninger for destinationer med samme oprindelse eller for sikre (HTTPS) destinationswebadresser fra en sikker side.
  • oprindelse: Sender kun oprindelsen (skema, vært og port).
  • origin-when-cross-origin: Sender den fulde URL for anmodninger om samme oprindelse, men kun oprindelsen for andre tilfælde.
  • same-origin: Sender en fuld henvisningsadresse for anmodninger om samme oprindelse, men ingen header for anmodninger om krydsoprindelse.
  • strict-origin: Sender oprindelsen for HTTPS-anmodninger, men ingen header for HTTP-anmodninger.
  • strict-origin-when-cross-origin: Sender fuld henvisning til anmodninger med samme oprindelse, oprindelse til HTTPS-destinationer fra HTTPS-sider og ingen header til HTTP-destinationer.
  • unsafe-url: Sender fuld URL uanset oprindelse eller sikkerhed (anbefales ikke).

Eksempler på udvidede NGINX-konfigurationer

SSL/TLS-konfiguration

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Referrer-Policy "no-referrer";

    # Additional SSL configurations
}

Denne konfiguration anvender Referrer-Policy-headeren i et sikkert, SSL/TLS-aktiveret miljø, hvilket forbedrer privatlivets fred på krypterede forbindelser.

Multi-Domain Server Konfiguration

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Referrer-Policy "no-referrer";

    # Additional configurations for each domain
}

Denne opsætning sikrer, at Referrer-Policy-headeren anvendes på tværs af flere domæner, der hostes på den samme server, og opretholder konsistente privatlivsindstillinger.

Implementering af tilladelser-politik i NGINX

Forståelse af tilladelser-politik

Overskriften Permissions-Policy giver webadministratorer præcis kontrol over browserfunktioner og API'er på deres websteder. Konfiguration af denne header styrker webstedets sikkerhed og privatliv betydeligt, hvilket muliggør funktionsbegrænsninger såsom geoplacering, kamera og mikrofon baseret på dit websteds specifikke behov.

Konfiguration af Permissions-Policy i NGINX

For at inkorporere Permissions-Policy-headeren i din NGINX-server skal du ændre NGINX-konfigurationsfilen, normalt placeret på /etc/nginx/nginx.conf eller i mappen /etc/nginx/sites-available/.

Tilføj følgende direktiv til serverblokken:

add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

Dette direktiv lister forskellige browserfunktioner og API'er, og indstiller dem alle til (), hvilket effektivt deaktiverer dem. Denne konfiguration giver en omfattende tilgang til at begrænse funktioner, der kan kompromittere brugernes privatliv eller sikkerhed.

Eksempel på NGINX-konfiguration med Permissions-Policy

Her er et eksempel på, hvordan din NGINX-konfiguration kan se ud med Permissions-Policy-headeren:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Dette direktiv indeholder en omfattende liste over forskellige browserfunktioner og API'er, og indstiller dem til () for effektivt at deaktivere dem.

Eksempel på NGINX-konfiguration med Permissions-Policy

Din NGINX-konfiguration, inklusive Permissions-Policy, kan se sådan ud:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Genindlæs NGINX med sudo systemctl genindlæs nginx eller sudo nginx -s genindlæs efter at have foretaget disse ændringer.

Tilladelser-Politikindstillinger forklaret

Overskriften Permissions-Policy giver dig mulighed for at tilpasse brugen af ​​forskellige funktioner:

  • geolokation: Styrer adgang til geolokaliseringsdata.
  • midi: Administrerer adgang til MIDI-enheder.
  • meddelelser: Styrer visning af meddelelser.
  • skubbe: Påvirker push-meddelelsesfunktionalitet.
  • sync-xhr: Relaterer til synkron XMLHTTPRequest.
  • accelerometer: Dikterer adgang til enhedens accelerometer.
  • gyroskop: Styrer adgangen til gyroskopet.
  • magnetometer: Styrer adgangen til enhedens magnetometer.
  • betaling: Gælder for betalingsanmodningsfunktioner.
  • usb: Styrer adgang til USB-enheder.
  • vr: Vedrører virtual reality-funktioner.
  • kamera: Styrer kameraadgang.
  • mikrofon: Dikterer mikrofonadgang.
  • højttaler: Styrer adgangen til højttalerenheder.
  • vibrere: Påvirker vibrations-API.
  • omgivende lys-sensor: Relaterer til sensoren for det omgivende lys.
  • automatisk afspilning: Styrer automatisk afspilning af medier.
  • krypteret-medie: Styrer krypteret medieadgang.
  • udføre-udklipsholder: Styrer læse-/skriveadgang til udklipsholder.
  • dokument-domæne: Vedrører funktionen document.domain.
  • Fuld skærm: Dikterer fuldskærmsadgang.
  • billedoptagelse: Styrer billedoptagelsesfunktionalitet.
  • lazyload: Påvirker doven indlæsning af billeder.
  • legacy-billedformater: Relaterer til ældre billedformater.
  • overdimensionerede billeder: Styrer indlæsning af overdimensionerede billeder.
  • uoptimerede-tabsgivende-billeder: Håndterer uoptimerede billeder med tab.
  • uoptimerede-tabsfri-billeder: Vedrører uoptimerede billeder uden tab.
  • medier i ustørrelse: Styrer medier uden eksplicit størrelse.
  • lodret-rul: Påvirker lodret rulning.
  • web-deling: Relaterer til webdelingsfunktioner.
  • xr-spatial-tracking: Styrer XR rumlig sporing.

Avancerede konfigurationer af tilladelser-politik i NGINX

Konfiguration af tilladelser-politik med specifikke domæner og jokertegn

Ud over den grundlæggende opsætning af deaktivering af funktioner ved hjælp af (), kan Permissions-Policy i NGINX skræddersyes til at tillade visse funktioner fra specifikke domæner eller ved at bruge jokertegn. Denne avancerede konfiguration giver mere nuanceret kontrol over, hvad dit websted kan få adgang til, og hvorfra.

Eksempel: Tilladelse af funktioner fra specifikke domæner

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(https://trusteddomain.com), microphone=(https://alloweddomain.com)";

    location / {
        proxy_pass http://my_portal;
    }
}

Denne konfiguration tillader kun geolokationsdataadgang fra https://trusteddomain.com og mikrofonadgang udelukkende fra https://alloweddomain.com, hvilket øger sikkerheden ved at begrænse disse følsomme funktioner til betroede kilder.

Eksempel: Brug af jokertegn til brede tilladelser

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "camera=*; fullscreen=*";

    location / {
        proxy_pass http://my_portal;
    }
}

Jokertegnet * i denne opsætning tillader kameraadgang og fuldskærmstilstand fra ethvert domæne. Denne tilgang giver bredere tilladelser, velegnet til websteder, der kræver omfattende funktionsadgang fra forskellige kilder.

Eksempel: Kombination af begrænsninger og tilladelser

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "accelerometer=(); gyroscope=(self https://example2.com); payment=*";

    location / {
        proxy_pass http://my_portal;
    }
}

I denne konfiguration er accelerometeradgang deaktiveret, gyroskopadgang er tilladt fra det samme domæne og https://example2.com, og betalingsanmodninger er tilladt fra alle domæner.

Bekræftelse af sikkerhedsoverskrifter med Curl Command i NGINX

Brug af Curl til at kontrollere sikkerhedsoverskrifter

Curl-kommandoen er et værdifuldt værktøj til at verificere konfigurationen af ​​sikkerhedsheadere på din NGINX-server. Det giver dig mulighed for at inspicere dit websteds headere og bekræfte, at sikkerhedsheaderne er korrekt opsat. Dette verifikationstrin er afgørende for at sikre, at din webservers sikkerhedsforanstaltninger er aktive og fungerer efter hensigten.

Udførelse af Curl-kommandoen til headerbekræftelse

For at kontrollere overskrifterne på dit websted skal du udføre følgende kommando i din terminal:

curl -I http://example.com

Erstat example.com med dit domænenavn. Denne kommando anmoder om overskrifterne fra din server, hvilket giver indsigt i de aktive sikkerhedskonfigurationer.

Forventet output og fortolkning

Når du kører curl-kommandoen, bør du modtage output, der ligner følgende:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Mar 2023 00:00:00 GMT
Content-Type: text/html
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self';
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();"

Dette output bekræfter tilstedeværelsen og den korrekte konfiguration af forskellige sikkerhedsheadere på din server, såsom Strict-Transport-Security, Content-Security-Policy, X-XSS-Protection og andre. Hver overskrift, der er angivet i outputtet, spiller en specifik rolle i at sikre og beskytte din webserver mod forskellige websårbarheder.

Konklusion

Ved at konfigurere sikkerhedsheadere i NGINX øger du sikkerheden i dine webapplikationer markant. Gennemgå og opdater regelmæssigt dine sikkerhedsoverskrifter for at tilpasse sig til udvikling af sikkerhedstrusler. Implementering af disse overskrifter hjælper med at beskytte mod en lang række angreb og sikrer en sikrere browsingoplevelse for dine brugere. Oprethold årvågenhed og hold din NGINX-konfiguration opdateret for at beskytte dine webaktiver robust.

Joshua James
Følg mig
Seneste indlæg af Joshua James (se alt)

Sådan installeres Android Studio på Linux Mint 22, 21 eller 20

Sådan installeres Rust på Debian 12, 11 eller 10 Linux

Skriv en kommentar


Hvis du har nogen legitime forespørgsler, såsom forslag til artikler, så tøv ikke med at kontakte LinuxCapable. Sørg for, at din besked er skrevet på engelsk.

Kontakt os
Om os Ansvarsfraskrivelse Fortrolighedspolitik Vilkår og betingelser