Naar de inhoud
Recognized by Laravel Match je project Contact
Security en authenticatie

Implementeer een Content Security Policy (CSP)

Voor het laatst bijgewerkt op:

Introductie

Een Content Security Policy (CSP) is een security header die helpt om Cross-Site Scripting (XSS)-aanvallen en andere code-injectiekwetsbaarheden te voorkomen, door te definiëren welke bronnen van content geladen en uitgevoerd mogen worden in je webapplicatie.

Waarom

  • Voorkomt XSS-aanvallen - Blokkeert de uitvoering van kwaadaardige scripts die in je applicatie worden geïnjecteerd
  • Verkleint risico's op code-injectie - Beperkt het gebruik van inline scripts en eval()
  • Voorkomt data-exfiltratie - Bepaalt waar je applicatie data naartoe mag sturen
  • Bescherming tegen clickjacking - Voorkomt dat je site in kwaadaardige frames wordt ingebed
  • Voorkomt mixed content - Zorgt ervoor dat HTTPS-sites geen onveilige HTTP-bronnen laden
  • Compliance-eisen - Veel securitystandaarden vereisen inmiddels een CSP-implementatie

Geschikt voor

  • Alle Laravel-applicaties, met name die gevoelige data verwerken
  • Applicaties met door gebruikers gegenereerde content
  • E-commerce- en financiële applicaties
  • Applicaties die aan security-compliance moeten voldoen
  • Publiek toegankelijke webapplicaties

Minder geschikt voor

  • Legacy-applicaties met veel inline scripts die niet gerefactord kunnen worden
  • Applicaties in een vroeg ontwikkelstadium met snel veranderende contentbronnen
  • Interne tools met zeer gecontroleerde gebruikerstoegang (hoewel nog steeds aanbevolen)

Meer info

Skill

Laravel Boost Skill

Gebruik deze skill om de richtlijn rechtstreeks toe te passen met een AI-assistent.

Use this skill when a Laravel task touches this best practice. It is self-contained so it can be installed independently by Laravel Boost or another agent-skill system.

## Core Guidance

Content Security Policy (CSP) is a security header that helps prevent Cross-Site Scripting (XSS) attacks and other code injection vulnerabilities by defining which sources of content are allowed to be loaded and executed on your web application.

## Why It Matters

- **Prevents XSS attacks** - Blocks execution of malicious scripts injected into your application
- **Reduces code injection risks** - Restricts inline scripts and eval() usage
- **Prevents data exfiltration** - Controls where your application can send data
- **Clickjacking protection** - Prevents your site from being embedded in malicious frames
- **Mixed content prevention** - Ensures HTTPS sites don't load insecure HTTP resources
- **Compliance requirements** - Many security standards now require CSP implementation

## Apply When

- All Laravel applications, especially those handling sensitive data
- Applications with user-generated content
- E-commerce and financial applications
- Applications requiring security compliance
- Public-facing web applications

## Be Careful When

- Legacy applications with extensive inline scripts that cannot be refactored
- Applications in early development with rapidly changing content sources
- Internal tools with very controlled user access (though still recommended)

## Canonical Source

- Full best practice: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/security-and-authentication/implement-content-security-policy/BEST_PRACTICE.md
- Dutch translation: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/security-and-authentication/implement-content-security-policy/translations/nl.md

## Workflow

1. Inspect the user's Laravel code before recommending changes.
2. Identify the narrow rule from this best practice that applies to the task.
3. Prefer Laravel's built-in conventions and documented APIs over custom abstractions.
4. Keep examples focused on this practice; reference other skills or practices when the task crosses boundaries.
5. Verify code changes with the project's available tests, linters, static analysis, or framework checks.

## Review Checklist

- The recommendation is Laravel-specific and grounded in this practice.
- Code examples use realistic Laravel file names, class names, and method names.
- The advice avoids mixing unrelated architecture, deployment, security, or testing topics.
- Related practices are mentioned when useful, but not re-explained in full.
- Dutch output, when requested, keeps framework and API names intact.