Laravel en Filament security voor maatwerk dat ertoe doet
Laravel geeft je goede bouwstenen: policies, CSRF, hashing, rate limiting. Het gaat mis waar ze niet gebruikt worden. Wij controleren je app, API's en Filament-panels op precies die plekken en bouwen security in je workflow.
- Autorisatie per model en endpoint
- Livewire en Filament up-to-date
- Security-checks in je CI-pipeline
Het framework is veilig. Je code moet het nog worden.
Een Laravel-app is zelden gehackt via een lek in Laravel zelf. De lekken zitten in wat er bovenop gebouwd is. Een controller die een order ophaalt op ID zonder te checken of die van de ingelogde gebruiker is. Een model zonder $fillable. Een Filament-panel dat publiek bereikbaar is op een Livewire-versie met een bekend lek.
Juist bij maatwerk zit de waarde vaak in data: klantportals, B2B-bestelomgevingen, koppelingen met ERP en betaalsystemen, interne tools met Filament. Die apps verwerken persoonsgegevens, prijsafspraken en orders. Een fout in autorisatie raakt dan direct je klanten.
Wij bouwen zelf Laravel- en Filament-apps en reviewen ze met dezelfde blik. We kennen de patronen die goed gaan en de shortcuts die in een deadline-week toch in productie belanden.
OWASP Top 10:2025 in een Laravel-app
Per risico: wat Laravel al voor je regelt, en waar het in de praktijk misgaat.
| OWASP 2025 | Wat Laravel biedt | Waar het misgaat |
|---|---|---|
| A01 Broken Access Control | Policies, Gates, authorize() in Form Requests, scoped route bindings | Policies wel geschreven, niet aangeroepen. Records ophalen op ID zonder ownership-check (IDOR). |
| A02 Security Misconfiguration | Aparte environments, config:cache, debug uit te zetten | APP_DEBUG=true in productie, .env of .git publiek bereikbaar, standaard Filament-panel zonder toegangscheck. |
| A03 Software Supply Chain Failures | Composer met lockfile, composer audit | Lockfile niet in git, updates maanden uitgesteld, packages zonder onderhoud. |
| A04 Cryptographic Failures | Hash-facade, Crypt met APP_KEY, encrypted casts | APP_KEY gedeeld tussen omgevingen of in git, gevoelige velden onversleuteld opgeslagen. |
| A05 Injection | Eloquent en Query Builder met parameter binding, Blade-escaping | DB::raw of whereRaw met user-input, {!! !!} op gebruikersdata, orderBy op een vrije kolomnaam uit de request. |
| A06 Insecure Design | Bouwstenen, geen ontwerp | Geen limiet op kortingscodes of acties, businesslogica die alleen in de frontend wordt gecontroleerd. |
| A07 Authentication Failures | Starter kits, Sanctum, ingebouwde login-throttling | Eigen login zonder rate limiting, API-tokens zonder verloop of scopes, geen 2FA op beheer. |
| A08 Software or Data Integrity Failures | Signed URLs, encrypted cookies | Unserialize op onbetrouwbare data, webhooks zonder handtekening-check. |
| A09 Security Logging & Alerting Failures | Logging-channels, events | Geen log van admin-acties, of logs met wachtwoorden, tokens en persoonsgegevens erin. |
| A10 Mishandling of Exceptional Conditions | Exception handler, transacties | Stacktraces naar de gebruiker, halve orders na een fout in een externe API, fail-open bij een time-out. |
Livewire en Filament: updates zijn security
In juli 2025 werd CVE-2025-54068 bekend: een remote code execution-lek in Livewire v3, via de manier waarop componenten worden gehydrateerd. Filament v3 draait op Livewire. Een Filament-panel op een kwetsbare Livewire-versie was daarmee ook kwetsbaar, ook als je zelf nooit een Livewire-component schreef.
Dat illustreert het probleem met admin-panels. Ze zijn snel gebouwd en vaak publiek bereikbaar op /admin. Ze geven toegang tot alle data. En ze hangen af van een keten packages die je niet zelf onderhoudt. Wie updates uitstelt, draait op een gegeven moment een bekend lek.
Wij houden Livewire, Filament en de rest van je dependencies bij met composer audit en een vast update-ritme. We zetten panels waar mogelijk achter IP-beperking of VPN, en controleren dat canAccessPanel op je User-model echt beperkt wie binnenkomt. Filament-resources krijgen policies, zodat een gebruiker met toegang tot het panel nog niet alles kan zien.
PHP zelf hoort bij dezelfde keten. Het PHP2Shell-lek van oktober 2026 liet zien dat ook de runtime onder je app kritieke updates nodig heeft.
Wat we controleren in een Laravel security audit
We lezen code, configuratie en de draaiende omgeving. Geen geautomatiseerde scan met een PDF eromheen.
Autorisatie
- Elke route en elk endpoint: wie mag dit aanroepen en wordt dat gecheckt
- Policies op alle modellen met gevoelige data, ook in Filament-resources
- Ownership-checks bij ophalen op ID, ook in API's en downloads
- Multi-tenant scheiding: kan klant A data van klant B zien
Input en output
- Validatie via Form Requests, ook op API-endpoints
- Mass assignment: $fillable of $guarded op elk model
- Raw queries, dynamische kolomnamen en sortering
- Blade-output zonder escaping en HTML uit gebruikersinput
Uploads en bestanden
- Validatie op type en grootte, niet alleen op extensie
- Opslag buiten de publieke webroot, download via een gecontroleerde route
- Geen uitvoerbare bestanden in publiek bereikbare mappen
- Livewire temporary uploads en opruimen ervan
Secrets en configuratie
- APP_DEBUG uit en APP_KEY uniek per omgeving
- .env niet in git en niet bereikbaar via de webserver
- API-keys van externe diensten met minimale rechten
- Rotatie na vertrek van teamleden of na een incident
API's en authenticatie
- Sanctum- of Passport-tokens met verloop en abilities
- Rate limiting op login, wachtwoord-reset en publieke endpoints
- Webhook-handtekeningen verifiëren
- CORS beperkt tot domeinen die het nodig hebben
Security in je CI-pipeline
Een audit is een momentopname. Security in je pipeline houdt het daarna op niveau, zonder dat iemand eraan hoeft te denken.
composer audit en npm audit
Bij elke build controleren op bekende lekken in dependencies. Een kritieke melding blokkeert de deploy, een lage wordt een ticket.
Lees verder →Statische analyse
Larastan of PHPStan op een zinvol niveau, aangevuld met regels die gevaarlijke patronen vinden zoals raw queries met variabelen.
Lees verder →Secrets-scanning
Voorkomen dat API-keys, tokens of een .env-bestand per ongeluk in een commit belanden. Eenmaal in git, altijd in git.
Tests op autorisatie
Feature-tests die met twee gebruikers controleren dat de één niet bij de data van de ander kan. Dat vangt IDOR-regressies voordat ze live staan.
Lees verder →Wanneer is dit niet nodig?
Een interne tool zonder persoonsgegevens, alleen bereikbaar via VPN, met drie gebruikers, heeft geen volledige audit nodig. Daar volstaan updates, een korte configuratiecheck en goede back-ups.
Een klantportal met orderhistorie, een B2B-omgeving met prijsafspraken of een API die met je ERP en betaalprovider praat, is een ander verhaal. Daar raakt een fout direct klanten en omzet, en daar loont een grondige review.
We zeggen eerlijk in welke categorie je app valt. Soms is een pentest de betere keuze, soms een audit, soms alleen een update-ritme.
Zo werken we
Een Laravel security-traject is altijd code-gedreven. We lezen wat er gebouwd is, niet alleen wat er van buiten zichtbaar is.
- 1
1. Kennismaking en scope
Welke app, welke gebruikers, welke data, welke koppelingen. We bepalen samen wat de meeste aandacht verdient.
- 2
2. Code en configuratie lezen
Toegang tot repository en omgeving. We lopen routes, controllers, policies, models en config systematisch door.
- 3
3. Testen in de draaiende app
Op staging testen we autorisatie met meerdere rollen, uploads, API-endpoints en foutafhandeling.
- 4
4. Rapport met prioriteiten
Bevindingen met risico, bewijs en een concrete oplossing in Laravel-termen. Bovenaan wat het eerst moet.
- 5
5. Fixen en borgen
Wij lossen de bevindingen op of begeleiden je team. Daarna zetten we checks in de CI-pipeline en een update-ritme neer.
Wat je krijgt
- Review van autorisatie op routes, API's, models en Filament-resources
- Overzicht van dependencies met bekende lekken, inclusief Livewire en Filament
- Controle van uploads, secrets en productie-configuratie
- Rapport met bevindingen, risico, bewijs en concrete fix per punt
- Feature-tests voor autorisatie op de kritieke plekken
- composer audit, statische analyse en secrets-scanning in je CI
- Afspraken over een vast update-ritme
Waarom Coding.nl
We bouwen het zelf
Laravel-maatwerk en Filament-panels zijn ons dagelijks werk. We reviewen met kennis van hoe zulke apps echt gebouwd worden, en waar de shortcuts zitten.
Vast senior team, direct contact
Geen tussenlagen. Je bespreekt bevindingen met de persoon die ze vond, en die kan ze ook oplossen.
E-commerce context
15+ jaar e-commerce. We kennen de koppelingen met Magento, Shopify, ERP en betaalproviders waar Laravel-apps vaak tussen zitten.
Eerlijk over scope
Niet elke app heeft een volledige audit nodig. We adviseren wat past bij de data en het risico, ook als dat een kleiner traject is.
Verder lezen
- ›Laravel security checklist voor productie
- ›Filament security: checklist voor productie (2026)
- ›Livewire en Filament updates: achterlopen is een security-risico
- ›OWASP Top 10 in Laravel: wat het framework regelt en wat jij doet
- ›Beveiligde file uploads in Laravel — PCI-DSS overwegingen
- ›Laravel Sanctum vs Passport — API authenticatie voor e-commerce
- ›API-beveiliging voor e-commerce integraties: wat je moet weten
- ›PHP2Shell: twee kritieke PHP-lekken waar elke webshop nu iets mee moet
Veelgestelde vragen
Je Laravel- of Filament-app laten doorlichten?
Vertel ons wat de app doet, welke data erin zit en wie hem gebouwd heeft. We stellen voor wat zinvol is: een audit, een pentest of alleen een update-ritme. Direct contact met het team dat het werk doet.