How we ensure your web application is secure

"But is all of that actually safe?" It's a question we developers get from time to time. And rightly so, because a web application often handles customer data, orders, business processes, and usually personal information as well, making security and privacy (GDPR) go hand in hand. The honest answer is that 100% online security doesn't exist. What we can do: make it as difficult as possible for attackers. We don't do this with a single measure, but with multiple layers that reinforce each other. In this blog, we'll show you the choices we make and why.

Author: Jordi van den Broek

Published: 29 July, 2026

We build on a solid framework: Laravel

We work with Laravel, one of the most widely used and best-maintained frameworks for web applications. Much of the security is built in by default: protection against attacks, such as someone trying to inject malicious code through a form or take over a logged-in user, is handled by the framework as long as we use it correctly. So we don't have to reinvent the wheel for every project, but instead build on a foundation that is tested and improved worldwide every day.

No code goes live without double checks

Good security starts before any code goes live. With us, no change makes it into the application without a second developer critically reviewing it. This four-eyes principle is intentional: what one person misses, the other catches. Besides producing cleaner code, it also prevents mistakes or unsafe constructions from slipping through unnoticed.

On top of that, we have an automated check. Every change must pass through our pipeline before being released: tests run automatically, and code analysis checks for errors and risks. If anything fails, nothing goes live.

We use separate environments for development, testing, and production (DTAP). New features and updates are first tested by us on the test environment and later on staging, never directly on the live environment where your users and data reside.

"We deliberately perform both human and automated checks at a stage where mistakes are still easy to fix."

– Jordi - developer bij Dolphiq

De stappen die wij zetten om veiligheid te waarborgen.

Veiligheid is geen los onderdeel dat je achteraf toevoegt, maar iets dat in elke laag van een applicatie terugkomt. Van de server tot de code en van toegang tot updates: dit zijn de stappen die wij standaard zetten.

Serverniveau

Grenzen stellen begint bij de webserver

Alleen vertrouwde bronnen krijgen toegang

Op het niveau van de webserver (nginx) valt winst te behalen. Met security headers sturen we instructies mee naar de browser, bijvoorbeeld dat verkeer altijd via een beveiligde verbinding loopt en dat de site niet binnen een andere website getoond mag worden. En met CORS (Cross-Origin Resource Sharing) bepalen we welke domeinen contact mogen maken met de applicatie of API, zodat alleen vertrouwde bronnen toegang krijgen.

Van beveiligde verbinding tot gehashte wachtwoorden

Versleuteling

We versleutelen gegevens

Gegevens moeten veilig zijn, zowel 'onderweg' als wanneer ze ergens opgeslagen staan. Daarom versturen we alles via een beveiligde verbinding (TLS 1.2 of hoger) en bewaren we gevoelige gegevens en back-ups in versleutelde vorm (AES-256). Wachtwoorden slaan we nooit gewoon leesbaar op, maar alleen als onomkeerbare hash. Zo is jouw data beschermd, zowel onderweg als in opslag.

Toegang

Niet iedereen hoeft overal bij te kunnen

Rollen, rechten en verplichte tweestapsverificatie

Veiligheid gaat niet alleen over de applicatie, maar ook over wie er toegang toe heeft. We werken met rollen en rechten (RBAC), zodat niemand meer rechten heeft dan nodig, en toegang is beveiligd met verplichte tweestapsverificatie (2FA). Wachtwoorden en sleutels slaan we beveiligd op in onze eigen tool ncr.pt. Alleen een select aantal (senior/lead) developers kan bij de productieomgeving.

Direct handelen

We zien aanvalspogingen meteen

Monitoring

Ook met goede bescherming wil je weten wat er op je applicatie gebeurt. Daarom gebruiken we monitoring (Sentry) die ons in real time waarschuwt zodra er iets afwijkt, inclusief verdachte pogingen om binnen te komen. Zo ontdekken we problemen niet pas weken later in een logbestand, maar direct, en kunnen we ook meteen handelen.

Updates

Bijblijven is de beste verdediging

Regelmatige update-rondes, ook voor de kleinere updates

Software is nooit "af". Dagelijks worden er beveiligingslekken gevonden in frameworks en in de losse onderdelen die een applicatie gebruikt. Daar komen reparaties voor uit, maar die helpen alleen als je ze ook installeert. We draaien daarom gestructureerde update-rondes, juist óók de kleinere tussentijdse updates. Niet spannend en zelden zichtbaar voor de eindgebruiker, maar wel een van de meest effectieve acties om veilig te blijven.

Toeleveringsketen

We beschermen de toeleveringsketen

Bescherming tegen supply chain-aanvallen

Een moderne applicatie bestaat niet alleen uit code die wij zelf schrijven. Ze gebruikt tientallen, soms honderden kant-en-klare bouwstenen (packages) uit de open-source-wereld. Dat is doorgaans betrouwbaar, maar het is ook een route die aanvallers steeds vaker misbruiken: ze smokkelen kwaadaardige code in een populair pakket, dat vervolgens ongemerkt in duizenden applicaties belandt. Dit soort supply chain-aanvallen is recent flink toegenomen, ook in de Laravel-wereld.

Daar beschermen we ons op twee fronten tegen. Aan de PHP-kant gebruiken we de nieuwste versie van de software dat deze 'bouwstenen' binnenhaalt (Composer). Sinds versie 2.10 controleert dat elk pakket automatisch tegen een actuele lijst van bekende malware en blokkeert het dat nog vóór installatie. Voor onze overige tooling hebben we een extra controle aan onze pipelines toegevoegd (Aikido Safe Chain), die hetzelfde doet en bovendien nieuwe pakketten even tegenhoudt, precies het moment waarop ze het vaakst misbruikt worden.

Zo wordt kwaadaardige code tegengehouden voordat die geïnstalleerd wordt, zowel op onze eigen machines als in het geautomatiseerde proces dat de applicatie oplevert.

And as an extra: a pentest

If you want certainty about how robust an application really is, you can have a penetration test performed: a controlled attack by an independent specialist, such as Tex-Tribe. Their ethical hackers approach the application like a real attacker would, but with permission and without causing harm, and provide a clear report with their findings and recommendations. We then get to work on those. This can be especially useful for extra assurance or for audits and certifications.

We use AI responsibly

AI is rapidly changing the software landscape on both sides. On our side, code is increasingly (partially) generated by AI. This can help us develop faster, but AI delivers code that works, not necessarily code that is secure, and does so convincingly enough that mistakes can easily go unnoticed. That's why AI doesn't change our process: whether code is written by a human or with AI assistance, it goes through exactly the same checks: the four-eyes principle, tests, and code analysis in our pipeline. AI is a tool, not a replacement for the judgment of an experienced developer.

Veelgestelde vragen over software en veiligheid

Door realtime monitoring zien we afwijkingen direct, niet pas weken later. We hebben een vaste incidentprocedure: we onderzoeken het probleem, verhelpen het en informeren je als jouw applicatie of gegevens geraakt zijn. Versleutelde back-ups zorgen dat gegevens hersteld kunnen worden.
Het grootste deel ligt bij ons: updates, monitoring en de beveiliging van de omgeving. Wat bij jou ligt: zorgvuldig omgaan met inloggegevens en toegang van medewerkers. Tweestapsverificatie maken we daarom standaard onderdeel van de applicatie.
Nee, een penetratietest is niet verplicht, maar wel waardevol als je extra zekerheid wilt of als een audit of certificering erom vraagt. Een onafhankelijke specialist valt de applicatie gecontroleerd aan en rapporteert de bevindingen, waarna wij eventuele verbeterpunten oppakken.
Nee, want AI verandert niets aan onze werkwijze. Alle code, of die nu door een mens of met hulp van AI is geschreven, gaat door dezelfde controles: het vierogenprincipe, automatische tests en code-analyse. AI is gereedschap, geen vervanging van het oordeel van een ervaren ontwikkelaar.
Nee, beveiliging is geen optie of meerprijs, maar standaard onderdeel van hoe we bouwen. Het framework (Laravel), de dubbele controles, versleuteling en updates zitten in elk project. Alleen aanvullende wensen, zoals een onafhankelijke pentest, brengen aparte kosten met zich mee.

Security is not a one-time action

There is no button that instantly makes an application secure. It's a combination of a strong foundation, careful choices, vigilance, and staying up-to-date, possibly supplemented by an external test. We keep working on this throughout the entire lifecycle of a project, so you can focus on your business with peace of mind.

Moreover, these measures are not isolated: they are part of a structured, documented information security policy (ISMS) that we set up according to the principles of ISO 27001 and continuously evaluate.