Hoe beveiligingsheaders in Nginx te configureren

Het configureren van beveiligingsheaders in NGINX is essentieel voor het verbeteren van de beveiliging van uw webapplicaties. Beveiligingsheaders beschermen tegen verschillende aanvallen, zoals cross-site scripting (XSS), clickjacking en andere aanvallen met code-injectie. Ze instrueren de browser over hoe om te gaan met de inhoud van uw site, waardoor een extra beveiligingslaag wordt geboden.

Deze handleiding leidt u door de stappen voor het configureren van beveiligingsheaders in NGINX, zodat u uw webapplicaties kunt beveiligen en de algehele beveiliging kunt verbeteren.

Implementatie van HTTP Strict Transport Security (HSTS) in NGINX

HSTS begrijpen

HTTP Strict Transport Security (HSTS) is een cruciaal beveiligingsprotocol voor websites. Het dwingt af dat verbindingen met een domein uitsluitend via HTTPS verlopen. Dit beperkt risico's zoals man-in-the-middle-aanvallen en waarborgt de integriteit en vertrouwelijkheid van gegevens die online worden verzonden. Wanneer een gebruiker probeert toegang te krijgen tot een site via HTTP, upgradet HSTS de verbinding automatisch naar HTTPS.

HSTS configureren in NGINX

Om HSTS in NGINX in te stellen, moet u het serverblok in het NGINX-configuratiebestand bijwerken. Dit bestand bevindt zich doorgaans op /etc/nginx/nginx.conf of binnen sitespecifieke configuraties op /etc/nginx/sites-available/. De update omvat het toevoegen van een header die de browser instrueert om altijd HTTPS te gebruiken voor het opgegeven domein.

Voeg in het serverblok voor uw domein de volgende regel toe:

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

Deze lijn bevat twee componenten:

max-age=31536000: Geef de browser opdracht om de komende 12 maanden HTTPS voor uw site te gebruiken.
includeSubDomains: Past het HSTS-beleid toe op alle subdomeinen van uw site voor uitgebreide beveiliging.

Voorbeeld NGINX-configuratie met HSTS

Uw NGINX-configuratie met de HSTS-header kan er als volgt uitzien:

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;
    }
}

Nadat u deze header hebt toegevoegd, laadt u NGINX opnieuw om de wijzigingen door te voeren met sudo systemctl reload nginx of sudo nginx -s reload.

Aanvullende NGINX-configuratievoorbeelden

Voor verschillende scenario's kan uw NGINX-configuratie met HSTS variëren. Hier zijn aanvullende voorbeelden:

Multi-domeinserver

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

    location / {
        # Configuration details
    }
}

Deze configuratie past HSTS toe op meerdere domeinen die op dezelfde server worden gehost. Elk vermeld domein dwingt HTTPS-verbindingen af.

Server met SSL-beëindiging

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
    }
}

Deze opstelling is bedoeld voor servers die SSL-beëindiging afhandelen. Het configureert HSTS op een beveiligde poort (443) met gespecificeerde SSL-certificaten, waardoor beveiligde verbindingen worden versterkt.

Content-Security-Policy (CSP) configureren in NGINX

CSP implementeren in NGINX

Het integreren van een Content-Security-Policy (CSP) in NGINX is een strategische zet om de beveiliging van webapplicaties te verbeteren. Het gaat om het toevoegen van een specifieke header binnen het serverblok van uw NGINX-configuratiebestand. Meestal te vinden in /etc/nginx/nginx.conf of in de map /etc/nginx/sites-available/. Dit bestand vereist zorgvuldige bewerking om CSP effectief toe te passen.

Voor een fundamentele CSP-installatie voegt u de volgende regel toe aan het serverblok:

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

Deze richtlijn beperkt het laden van inhoud naar het domein van de website ('self'), waardoor het risico op kwaadaardige externe uitvoering van inhoud aanzienlijk wordt verminderd.

Voorbeeld NGINX-configuratie met CSP

Uw NGINX-configuratie met de basis-CSP-richtlijn zou er als volgt uit kunnen zien:

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;
    }
}

Herlaad NGINX met sudo systemctl reload nginx of sudo nginx -s reload na het toevoegen van deze richtlijn.

CSP aanpassen aan specifieke behoeften

CSP kan worden afgestemd op de specifieke beveiligingsbehoeften van uw website. Hier vindt u uitgebreide configuraties voor verschillende scenario's:

Afbeeldingen van elke bron toestaan

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

Deze configuratie maakt het laden van afbeeldingen vanuit elke bron mogelijk, waarbij strikte controle over andere soorten inhoud behouden blijft.

Specifieke scripts en stijlconfiguratie

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

Met deze instelling zijn scripts uit uw domein en een vertrouwde externe bron naast inline stijlen mogelijk, waardoor functionaliteit en beveiliging in evenwicht worden gebracht.

CSP-richtlijnen en -opties verkennen

Richtlijnen in CSP

CSP-richtlijnen zijn regels die het beleid voor specifieke inhoudstypen definiëren. Gemeenschappelijke richtlijnen zijn onder meer:

default-src: het standaardbeleid dat op de meeste inhoudstypen wordt toegepast.
script-src: Beheert de bronnen voor JavaScript-bronnen.
style-src: Specificeert toegestane bronnen voor CSS-bronnen.
img-src: Beheert de bronnen voor afbeeldingsbronnen.
connect-src: Stelt beleid in voor netwerkverbindingen zoals XMLHttpRequest, WebSocket en EventSource.

Bronexpressies in CSP

Bronexpressies definiëren toegestane bronnen voor elke richtlijn:

'geen': Blokkeert alle bronnen.
'self': Staat grondstoffen van dezelfde oorsprong toe.
'unsafe-inline': Staat inline bronnen toe, zoals stijlen of JavaScript-URL's.
'unsafe-eval': staat JavaScript toe eval() functies en vergelijkbare methoden.
https:: Schakelt bronnen in vanaf elke HTTPS-URL.

X-XSS-bescherming configureren in NGINX

Inleiding tot X-XSS-bescherming

X-XSS-Protection, of de Cross-Site Scripting-header, is essentieel voor het beschermen van webapplicaties tegen XSS-aanvallen (Cross-Site Scripting). Deze header wordt ondersteund door grote webbrowsers zoals Chrome, Internet Explorer en Safari en verbetert de webbeveiliging door het laden van pagina's te voorkomen wanneer gereflecteerde XSS-aanvallen worden gedetecteerd.

X-XSS-bescherming inschakelen in NGINX

Het integreren van de X-XSS-Protection-header in uw NGINX-serverconfiguratie versterkt de native XSS-bescherming van de browser. Om deze beveiligingsfunctie in te schakelen, opent u uw NGINX-configuratiebestand, meestal gelegen op /etc/nginx/nginx.conf of in de map /etc/nginx/sites-available/.

Voeg deze instructie in het serverblok van uw NGINX-configuratiebestand in:

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

Deze richtlijn bestaat uit twee delen:

1: Activeert het XSS-filter van de browser.
mode=block: Geeft de browser opdracht om de pagina te blokkeren als een XSS-aanval wordt gedetecteerd, in plaats van te proberen deze op te schonen.

Voorbeeld NGINX-configuratie met X-XSS-bescherming

Een voorbeeld van een NGINX-configuratie inclusief X-XSS-Protection kan er als volgt uitzien:

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;
    }
}

Nadat u deze header hebt toegevoegd, laadt u NGINX opnieuw met behulp van sudo systemctl reload nginx of sudo nginx -s reload.

Aanvullende NGINX-configuratiescenario's

Voor een server met 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
}

Deze configuratie is voor servers met SSL, zodat X-XSS-Protection actief is op gecodeerde verbindingen.

Meerdere domeinen beheren

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

    # Further configuration
}

Deze configuratie past X-XSS-beveiliging toe op meerdere domeinen die op één server worden gehost.

X-Frame-opties configureren in NGINX

De rol van X-Frame-opties

X-Frame-Options is een essentiële beveiligingsheader die is ontworpen om websites te beschermen tegen clickjacking-aanvallen. Het voorkomt dat webpagina's worden weergegeven in frames of iframes, die vaak bij deze aanvallen worden gebruikt. Ondersteund door alle grote webbrowsers biedt X-Frame-Options wijdverbreide bescherming, waardoor de veiligheid van uw aanwezigheid op het internet op verschillende platforms wordt verbeterd.

Implementatie van X-Frame-opties in NGINX

Het opnemen van de X-Frame-Options-header in uw NGINX-serverconfiguratie is cruciaal voor het verbeteren van de beveiliging van uw site. Deze taak omvat het bewerken van het NGINX-configuratiebestand, meestal te vinden in /etc/nginx/nginx.conf of in de map /etc/nginx/sites-available/.

Om deze beveiligingsfunctie in te schakelen, voegt u de volgende instructie toe aan het serverblok in uw NGINX-configuratiebestand:

add_header X-Frame-Options "DENY";

Deze richtlijn, ingesteld op “DENY”, instrueert de browser om elke poging om de pagina in een frame of iframe weer te geven te blokkeren, wat een robuuste verdediging tegen clickjacking biedt.

Voorbeeld NGINX-configuratie met X-Frame-opties

Een voorbeeld van een NGINX-installatie met de X-Frame-Options-header is als volgt:

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;
    }
}

Nadat u deze header heeft toegevoegd, is het belangrijk om NGINX opnieuw te laden om de wijzigingen te activeren. Dit kan gedaan worden met sudo systemctl reload nginx of sudo nginx -s reload.

Uitbreiding van de NGINX-configuratie voor X-Frame-opties

Voor SSL-compatibele servers

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
}

Deze configuratie is voor servers met SSL, zodat X-Frame-Options wordt afgedwongen op beveiligde verbindingen.

Meerdere domeinen beheren

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

    # Additional configuration
}

Deze opstelling past de X-Frame-Options-header toe op meerdere domeinen op dezelfde server, waardoor de beveiliging voor elk domein wordt versterkt.

Implementatie van X-Content-Type-opties in NGINX

Rol van X-Content-Type-opties

X-Content-Type-Options is een essentiële beveiligingsheader in webbeveiliging die voorkomt dat browsers MIME-achtig snuffelen. Deze header versterkt dat browsers het aangegeven inhoudstype in HTTP-headers respecteren, waardoor beveiligingsproblemen worden aangepakt die kunnen optreden wanneer browsers bestandstypen verkeerd interpreteren, zoals het behandelen van afbeeldingsbestanden als uitvoerbare HTML, wat zou kunnen leiden tot cross-site scripting (XSS)-aanvallen.

X-Content-Type-opties instellen in NGINX

Om de beveiliging van uw webserver te verbeteren met de X-Content-Type-Options header, moet u het NGINX-configuratiebestand eenvoudig wijzigen. Dit bestand is meestal te vinden in /etc/nginx/nginx.conf of binnen sitespecifieke configuraties in /etc/nginx/sites-available/.

Neem deze header op door de volgende regel toe te voegen aan de server blok van uw NGINX-configuratie:

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

De “nosniff”-instelling zorgt ervoor dat de browser het door de server gespecificeerde inhoudstype strikt volgt, waardoor alternatieve interpretaties van de inhoud worden voorkomen.

Voorbeeld NGINX-configuratie met X-Content-Type-Options

Een NGINX-configuratie met X-Content-Type-Options kan als volgt zijn gestructureerd:

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;
    }
}

Nadat u uw configuratie hebt bijgewerkt, zorgt u ervoor dat u NGINX opnieuw laadt zodat de wijzigingen van kracht worden, met behulp van sudo systemctl reload nginx of sudo nginx -s reload.

Uitgebreide NGINX-configuratievoorbeelden

Configuratie voor 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
}

Deze opstelling is voor servers met SSL/TLS, waarbij X-Content-Type-Options worden toegepast op beveiligde verbindingen om de beveiliging te verbeteren.

Configuratie van meerdere domeinservers

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

    # Additional configurations for multiple domains
}

Deze configuratie past de X-Content-Type-Options-header toe op meerdere domeinen die op dezelfde server worden gehost, waardoor consistente beveiligingsinstellingen voor alle domeinen worden gegarandeerd.

Verwijzerbeleid configureren in NGINX

De functie van het verwijzingsbeleid

Referrer-Policy is een essentiële HTTP-header voor het verbeteren van de privacy en veiligheid van gebruikers op internet. Het bepaalt hoeveel verwijzingsinformatie wordt opgenomen in de Referer-header wanneer gebruikers van uw site naar anderen navigeren, waardoor gevoelige informatie wordt beschermd tegen openbaarmaking in webverzoeken.

Verwijzerbeleid instellen in NGINX

Om de Referrer-Policy-header in uw NGINX-server te implementeren, wijzigt u het NGINX-configuratiebestand, meestal te vinden op /etc/nginx/nginx.conf of in de map /etc/nginx/sites-available/. Voeg de volgende richtlijn toe aan het serverblok:

add_header Referrer-Policy "no-referrer";

Deze richtlijn, ingesteld op “no-referrer”, zorgt ervoor dat er geen verwijzende informatie wordt verzonden tijdens sitenavigatie, waardoor de privacy wordt gemaximaliseerd.

Voorbeeld NGINX-configuratie met verwijzingsbeleid

Uw NGINX-configuratie met de Referrer-Policy-header zou er als volgt uit kunnen zien:

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;
    }
}

Na het toevoegen van deze header laadt u NGINX opnieuw met opdrachten als sudo systemctl reload nginx of sudo nginx -s reload.

Verwijzerbeleidsopties en -definities

geen verwijzer: Er wordt geen verwijzerinformatie verzonden.
no-referrer-when-downgrade (standaard): Verzendt verwijzende informatie voor bestemmingen met dezelfde oorsprong of voor beveiligde (HTTPS) bestemmings-URL's vanaf een beveiligde pagina.
oorsprong: verzendt alleen de oorsprong (schema, host en poort).
origin-when-cross-origin: Verzendt de volledige URL voor verzoeken van dezelfde oorsprong, maar alleen de oorsprong voor andere gevallen.
same-origin: Stuurt een volledige referrer voor verzoeken van dezelfde oorsprong, maar geen header voor cross-origin-verzoeken.
strict-origin: verzendt de oorsprong voor HTTPS-verzoeken, maar geen header voor HTTP-verzoeken.
strict-origin-when-cross-origin: verzendt de volledige verwijzing naar verzoeken van dezelfde oorsprong, de oorsprong naar HTTPS-bestemmingen vanaf HTTPS-pagina's en geen header naar HTTP-bestemmingen.
unsafe-url: Verzendt de volledige URL, ongeacht herkomst of beveiliging (niet aanbevolen).

Uitgebreide NGINX-configuratievoorbeelden

SSL/TLS-configuratie

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
}

Deze configuratie past de Referrer-Policy-header toe in een veilige, SSL/TLS-compatibele omgeving, waardoor de privacy op gecodeerde verbindingen wordt verbeterd.

Configuratie van meerdere domeinservers

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

    # Additional configurations for each domain
}

Deze opstelling zorgt ervoor dat de header Referrer-Policy wordt toegepast op meerdere domeinen die op dezelfde server worden gehost, waardoor consistente privacy-instellingen behouden blijven.

Toestemmingsbeleid implementeren in NGINX

Inzicht in het machtigingenbeleid

De Permissions-Policy-header geeft webbeheerders nauwkeurige controle over browserfuncties en API's op hun websites. Het configureren van deze header vergroot de veiligheid en privacy van de site aanzienlijk, waardoor functiebeperkingen zoals geolocatie, camera en microfoon mogelijk worden gemaakt op basis van de specifieke behoeften van uw site.

Machtigingenbeleid configureren in NGINX

Om de Permissions-Policy header in uw NGINX-server op te nemen, wijzigt u het NGINX-configuratiebestand, meestal gelegen op /etc/nginx/nginx.conf of in de map /etc/nginx/sites-available/.

Voeg de volgende richtlijn toe aan het serverblok:

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=();";

Deze richtlijn vermeldt verschillende browserfuncties en API's en stelt ze allemaal in op (), waardoor ze effectief worden uitgeschakeld. Deze configuratie biedt een alomvattende aanpak voor het beperken van functies die de privacy of veiligheid van gebruikers in gevaar kunnen brengen.

Voorbeeld van een NGINX-configuratie met machtigingenbeleid

Hier is een voorbeeld van hoe uw NGINX-configuratie eruit zou kunnen zien met de header Permissions-Policy:

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;
    }
}

Deze richtlijn geeft een uitgebreid overzicht van verschillende browserfuncties en API's, en stelt deze in op () om ze effectief uit te schakelen.

Voorbeeld van een NGINX-configuratie met machtigingenbeleid

Uw NGINX-configuratie, inclusief Permissions-Policy, kan er als volgt uitzien:

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;
    }
}

Laad NGINX opnieuw met sudo systemctl reload nginx of sudo nginx -s reload nadat u deze wijzigingen heeft aangebracht.

Machtigingen-beleidsopties uitgelegd

Met de header Permissions-Policy kunt u het gebruik van verschillende functies aanpassen:

geolocatie: Beheert de toegang tot geolocatiegegevens.
midi: Beheert de toegang tot MIDI-apparaten.
meldingen: Beheert de weergave van meldingen.
duw: beïnvloedt de functionaliteit van pushmeldingen.
sync-xhr: Heeft betrekking op synchrone XMLHTTPRequest.
versnellingsmeter: dicteert toegang tot de versnellingsmeter van het apparaat.
gyroscoop: Regelt de toegang tot de gyroscoop.
magnetometer: Beheert de toegang tot de magnetometer van het apparaat.
betaling: is van toepassing op de functies voor betalingsverzoeken.
USB: Beheert de toegang tot USB-apparaten.
vr: Heeft betrekking op virtual reality-functies.
camera: Beheert cameratoegang.
microfoon: dicteert microfoontoegang.
spreker: regelt de toegang tot luidsprekerapparaten.
trillen: Beïnvloedt de vibratie-API.
omgevingslicht sensor: Heeft betrekking op de omgevingslichtsensor.
automatisch afspelen: Regelt het automatisch afspelen van media.
gecodeerde media: Beheert gecodeerde mediatoegang.
uitvoeren-klembord: Beheert de lees-/schrijftoegang tot het klembord.
document-domein: Heeft betrekking op de functie document.domain.
volledig scherm: dicteert toegang tot volledig scherm.
beeldopname: Beheert de functionaliteit voor het vastleggen van afbeeldingen.
luilast: beïnvloedt het lui laden van afbeeldingen.
oudere afbeeldingsformaten: Heeft betrekking op oudere afbeeldingsformaten.
extra grote afbeeldingen: Regelt het laden van te grote afbeeldingen.
niet-geoptimaliseerde afbeeldingen met verlies: Beheert niet-geoptimaliseerde afbeeldingen met verlies.
niet-geoptimaliseerde verliesvrije afbeeldingen: Heeft betrekking op niet-geoptimaliseerde, verliesvrije afbeeldingen.
niet-gedimensioneerde media: Beheert media zonder expliciete grootte.
verticaal scrollen: beïnvloedt verticaal scrollen.
web-share: Heeft betrekking op functies voor het delen van internet.
xr-ruimtelijke tracking: Beheert XR ruimtelijke tracking.

Geavanceerde configuraties van machtigingenbeleid in NGINX

Machtigingenbeleid configureren met specifieke domeinen en jokertekens

Naast de basisconfiguratie van het uitschakelen van functies met behulp van (), kan het machtigingsbeleid in NGINX worden aangepast om bepaalde functies van specifieke domeinen toe te staan of om jokertekens te gebruiken. Deze geavanceerde configuratie maakt een meer genuanceerde controle mogelijk over waartoe uw website toegang heeft en waar vandaan.

Voorbeeld: functies van specifieke domeinen toestaan

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;
    }
}

Deze configuratie staat alleen toegang tot geolocatiegegevens toe vanaf https://trusteddomain.com en microfoontoegang uitsluitend vanaf https://alloweddomain.com, waardoor de beveiliging wordt verbeterd door deze gevoelige functies te beperken tot vertrouwde bronnen.

Voorbeeld: jokertekens gebruiken voor brede machtigingen

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

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

Met het jokerteken * in deze configuratie is cameratoegang en volledig schermmodus vanuit elk domein mogelijk. Deze aanpak biedt bredere machtigingen, geschikt voor websites die uitgebreide toegang tot functies vanuit verschillende bronnen vereisen.

Voorbeeld: Beperkingen en machtigingen combineren

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

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

In deze configuratie is de toegang tot de accelerometer uitgeschakeld, is gyroscooptoegang toegestaan vanuit hetzelfde domein en https://example2.com, en zijn betalingsverzoeken toegestaan vanuit alle domeinen.

Beveiligingsheaders verifiëren met Curl Command in NGINX

Curl gebruiken om beveiligingsheaders te controleren

De opdracht curl is een waardevol hulpmiddel voor het verifiëren van de configuratie van beveiligingsheaders op uw NGINX-server. Hiermee kunt u de headers van uw website inspecteren en bevestigen dat de beveiligingsheaders correct zijn ingesteld. Deze verificatiestap is cruciaal om ervoor te zorgen dat de beveiligingsmaatregelen van uw webserver actief zijn en functioneren zoals bedoeld.

Het Curl-commando voor headerverificatie uitvoeren

Om de headers van uw website te controleren, voert u de volgende opdracht uit in uw terminal:

curl -I http://example.com

Vervang voorbeeld.com door uw domeinnaam. Dit commando vraagt de headers van uw server op, waardoor u inzicht krijgt in de actieve beveiligingsconfiguraties.

Verwachte output en interpretatie

Wanneer u de opdracht curl uitvoert, ontvangt u uitvoer die er ongeveer als volgt uitziet:

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=();"

Deze uitvoer bevestigt de aanwezigheid en correcte configuratie van verschillende beveiligingsheaders op uw server, zoals Strict-Transport-Security, Content-Security-Policy, X-XSS-Protection en andere. Elke header in de uitvoer speelt een specifieke rol bij het beveiligen en beschermen van uw webserver tegen verschillende webkwetsbaarheden.

Conclusie

Door security headers in NGINX te configureren, verbetert u de beveiliging van uw webapplicaties aanzienlijk. Controleer en update uw beveiligingsheaders regelmatig om ze aan te passen aan veranderende beveiligingsbedreigingen. Het implementeren van deze headers helpt u te beschermen tegen een breed scala aan aanvallen en zorgt voor een veiligere browse-ervaring voor uw gebruikers. Blijf waakzaam en houd uw NGINX-configuratie up-to-date om uw webmiddelen krachtig te beschermen.

Over
Laatste berichten

Volg mij

Joshua James

Joshua James is een ervaren Linux-systeembeheerder en eigenaar van linuxcapable.com. Hij heeft veel tutorials en handleidingen geschreven om gebruikers te helpen Linux-systemen te begrijpen. Joshua's expertise omvat een reeks Linux-distributies, waaronder Ubuntu, Fedora, Debian, RHEL, openSUSE en Arch Linux. Zijn passie is om gebruikers die nieuw zijn met Linux of Unix-achtige systemen te helpen leren van zijn kennis.

Volg mij

Laatste berichten van Joshua James (alles zien)

Hoe ModSecurity 2 met Apache op Debian 12 of 11 te installeren - dinsdag 17 september 2024
Hoe Remi RPM te installeren op Rocky Linux 9 of 8 - maandag, september 16, 2024
Hoe Akregator te installeren op Ubuntu 24.04, 22.04 of 20.04 - dinsdag, september 3, 2024

Implementatie van HTTP Strict Transport Security (HSTS) in NGINX

HSTS begrijpen

HSTS configureren in NGINX

Voorbeeld NGINX-configuratie met HSTS

Aanvullende NGINX-configuratievoorbeelden

Multi-domeinserver

Server met SSL-beëindiging

Content-Security-Policy (CSP) configureren in NGINX

CSP implementeren in NGINX

Voorbeeld NGINX-configuratie met CSP

CSP aanpassen aan specifieke behoeften

Afbeeldingen van elke bron toestaan

Specifieke scripts en stijlconfiguratie

CSP-richtlijnen en -opties verkennen

Richtlijnen in CSP

Bronexpressies in CSP

X-XSS-bescherming configureren in NGINX

Inleiding tot X-XSS-bescherming

X-XSS-bescherming inschakelen in NGINX

Voorbeeld NGINX-configuratie met X-XSS-bescherming

Aanvullende NGINX-configuratiescenario's

Voor een server met SSL

Meerdere domeinen beheren

X-Frame-opties configureren in NGINX

De rol van X-Frame-opties

Implementatie van X-Frame-opties in NGINX

Voorbeeld NGINX-configuratie met X-Frame-opties

Uitbreiding van de NGINX-configuratie voor X-Frame-opties

Voor SSL-compatibele servers

Meerdere domeinen beheren

Implementatie van X-Content-Type-opties in NGINX

Rol van X-Content-Type-opties

X-Content-Type-opties instellen in NGINX

Voorbeeld NGINX-configuratie met X-Content-Type-Options

Uitgebreide NGINX-configuratievoorbeelden

Configuratie voor SSL/TLS

Configuratie van meerdere domeinservers

Verwijzerbeleid configureren in NGINX

De functie van het verwijzingsbeleid

Verwijzerbeleid instellen in NGINX

Voorbeeld NGINX-configuratie met verwijzingsbeleid

Verwijzerbeleidsopties en -definities

Uitgebreide NGINX-configuratievoorbeelden

SSL/TLS-configuratie

Configuratie van meerdere domeinservers

Toestemmingsbeleid implementeren in NGINX

Inzicht in het machtigingenbeleid

Machtigingenbeleid configureren in NGINX

Voorbeeld van een NGINX-configuratie met machtigingenbeleid

Voorbeeld van een NGINX-configuratie met machtigingenbeleid

Machtigingen-beleidsopties uitgelegd

Geavanceerde configuraties van machtigingenbeleid in NGINX

Machtigingenbeleid configureren met specifieke domeinen en jokertekens

Voorbeeld: functies van specifieke domeinen toestaan

Voorbeeld: jokertekens gebruiken voor brede machtigingen

Voorbeeld: Beperkingen en machtigingen combineren

Beveiligingsheaders verifiëren met Curl Command in NGINX

Curl gebruiken om beveiligingsheaders te controleren

Het Curl-commando voor headerverificatie uitvoeren

Verwachte output en interpretatie

Conclusie

Plaats een reactie Reactie annuleren