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: 11 June, 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 check everything that comes in

Many issues start with external input: text in a form, a comment, a message. Malicious users can try to hide code in these. Wherever users are allowed to enter formatted text, we first "sanitize" that input with a proven tool (Purifier). This removes anything potentially dangerous and keeps only what is safe and intended.

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

– Jordi - developer bij Dolphiq

We set boundaries at the server level

There are also gains to be made at the web server level (nginx). With security headers, we send instructions to the browser, for example, to always use a secure connection and to prevent the site from being displayed within another website. And with CORS (Cross-Origin Resource Sharing), we specify which domains are allowed to interact with the application or API, so only trusted sources get access.

We encrypt data

Data must be secure both 'in transit' and at rest. That's why we send everything over a secure connection (TLS 1.2 or higher) and store sensitive data and backups in encrypted form (AES-256). Passwords are never stored in plain text, only as irreversible hashes. This way, your data is protected both in transit and in storage.

We control who has access

Security isn't just about the application, but also about who can access it. We use roles and permissions (RBAC), so everyone can only do what's relevant to their role, and access is secured with mandatory two-factor authentication (2FA). Passwords and keys are securely stored in our own tool ncr.pt. Only a select group of (senior/lead) developers can access the production environment.

We detect attacks instantly

Even with solid protection, you want to know what's happening on your application. That's why we use monitoring (Sentry) that alerts us in real time as soon as something unusual occurs, including suspicious attempts to break in. This way, we don't discover problems weeks later in a log file, but immediately, allowing us to act right away.

"We don't discover problems and attacks weeks later in a log file, but immediately."

We stay up-to-date with updates

Software is never "finished." Security vulnerabilities are discovered daily in frameworks and the various components an application uses. Fixes are released, but they're only effective if you actually install them. That's why we run structured update cycles, including the smaller interim updates. Not exciting and rarely visible to end users, but one of the most effective actions you can take to stay secure.

We protect the supply chain

A modern application isn't just made up of code we write ourselves. It uses dozens, sometimes hundreds, of ready-made building blocks (packages) from the open-source world. This is generally reliable, but it's also a route increasingly exploited by attackers: they sneak malicious code into a popular package, which then ends up unnoticed in thousands of applications. These types of supply chain attacks have increased significantly recently, even in the Laravel world.

We protect ourselves on two fronts. On the PHP side, we use the latest version of the software that manages these 'building blocks' (Composer). Since version 2.10, it automatically checks every package against an up-to-date list of known malware and blocks it before installation. For our other tooling, we've added an extra check to our pipelines (Aikido Safe Chain), which does the same and also temporarily blocks new packages, exactly when they're most often abused.

This way, malicious code is stopped before it can be installed, both on our own machines and in the automated process that delivers the application.

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.

AI makes it easier for attackers to attack

At the same time, AI also empowers attackers: probing an application or crafting convincing phishing emails is now faster, cheaper, and at a larger scale, increasing the number of attack attempts.

That's exactly why our layered approach works: no single measure can stop a determined attacker, but the combination of a solid foundation, clean input, server-level boundaries, monitoring, and timely updates makes their job increasingly difficult—whether the attacker is human or AI-powered.

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.