Tax data breach: what businesses need to remember to secure their applications

Tax data breach: what SMEs need to remember to secure their applications

The intrusions occurred in June and July. They involved, among other things, the usurpation of credentials belonging to a DGFiP agent and an authorised third party.

Investigations later revealed that certain data had been accessed and extracted. To date, 678,000 individuals and businesses are affected. The compromised information includes, in particular, the reference tax income, the family quotient, the withholding tax rate, and certain company-related data.

Important clarification: according to the ministry, users’ personal accounts were not compromised. Neither were the login credentials and passwords of individuals and businesses.

The incident remains, however, a very good reminder.

A data breach doesn’t always start with a hacker finding a major flaw in a website.

It can start with a compromised account.

Overly broad access rights.

A poorly monitored internal tool.

An exposed API.

A key stored in the wrong place.

Or an application that has worked perfectly for years, but whose security no one has truly reassessed.

And this issue is not limited to the government.

For an SME developing a business application, customer portal, or SaaS today, application security must be addressed much earlier in the project.

A data breach doesn’t necessarily mean the entire application was hacked

When we read that an organisation has been "hacked," the image is often the same.

We picture someone discovering a technical vulnerability, breaking into the server, and downloading the entire database.

In reality, scenarios are often more subtle.

In the DGFiP case, the ministry mentioned credential usurpation. The accounts used during the intrusions were indeed blocked after detection. But initial checks did not reveal the data extractions that had already taken place.

This is a key point for understanding application security.

Securing an application is not just about preventing someone from logging in.

You must also limit what a logged-in user can do.

You must know which data they can access.

You must be able to detect unusual behavior.

And you must keep enough logs to understand what happened after an incident.

OWASP, one of the leading references in application security, indeed lists authentication, access control, data protection, and logging among the key areas to check when securing a web application.

In other words, having a login screen with a strong password is just the start.

The more useful an application becomes, the more sensitive it becomes.

This is a common scenario we encounter with business applications.

A company first builds a small tool.

It’s used to track a few clients, manage a schedule, centralize requests, or replace an Excel file.

Initially, the scope is limited.

Then the tool works well.

Teams adopt it.

More users are added.

Then documents.

Then commercial data.

Then a CRM connection.

Then invoicing.

Then an API.

Then a Make or n8n automation.

Then possibly an AI layer.

Six months later, the small internal tool has become a critical part of the information system.

The application’s value has increased.

But its initial security level sometimes remains unchanged.

This is particularly common with prototypes, no-code applications, and apps quickly generated with AI. These technologies are not the issue in themselves. The problem arises when a tool designed to test an idea moves to production without revisiting its architecture.

We discuss this in particular in our guide on how to regain control of a Lovable application. A production application is more than just its interface. You must also examine the database, authentication, storage, roles, secrets, backend functions, webhooks, backups, and admin access.

The difference between a prototype and a true business application often lies here.

Application security starts with access rights

Let’s take a very simple example.

Your company has a back office used by 40 people.

A salesperson should only see their client accounts.

A sales manager should see their team’s accounts.

The management team may need access to the entire portfolio.

The technical administrator, however, should be able to manage users without necessarily accessing all business data.

If everyone has the same level of access, the application works.

But it is poorly designed.

A solid architecture applies the principle of least privilege: each user receives only the rights necessary to perform their job.

This is what limits the impact of a compromised account.

If a hacker gains access to a standard user’s credentials, they should not automatically obtain access to the entire database.

This is why we integrate roles, permissions, and access rules from the very design of our custom business applications.

On an architecture based, for example, on PostgreSQL and Supabase, this can also involve security policies applied directly at the data level.

The principle remains the same regardless of the stack: never assume an authenticated user has the right to see everything.

Strong authentication doesn’t solve everything, but it changes a lot

Credential theft is a classic scenario.

A password can be obtained via phishing, reused after a previous leak, or shared carelessly.

This is why sensitive applications benefit from adding multiple layers of protection.

Multi-factor authentication can reduce the risk of a simple password theft.

Session durations can be tailored to the sensitivity level.

Administrator accounts can follow stricter rules.

Technical access can be separated from human accounts.

An employee’s permissions can be revoked quickly when they change roles or leave the company.

The question is not just: "Do we have a login?"

The right question is: "What happens if that login falls into the wrong hands?"

This is a far more useful way to think aboutan SME’s cybersecurity.

An application must also be able to account for what happened

A secure application must produce useful audit trails.

Who logged in?

From which account?

What sensitive actions were performed?

Which user changed permissions?

How much data was accessed?

Does the behavior deviate entirely from the account’s usual activity?

An application that logs nothing may let an incident go unnoticed without the means to understand it.

Conversely, logs should not become a second sensitive database.

OWASP recommends logging security events and certain authentication or authorization operations, while avoiding the unnecessary recording of confidential information in logs.

Monitoring then makes these traces actionable.

A user accessing 30 customer records in a day may be normal.

The same account accessing 40,000 in a few minutes likely warrants an alert.

Security should not just block.

It must also be monitored.

API keys and secrets have become a major concern.

Modern applications communicate with a vast number of services.

Stripe.

OpenAI.

A CRM.

An email tool.

A business API.

Cloud storage.

A signing service.

Each integration often adds an API key, token, or secret.

And these secrets sometimes grant access to highly powerful functions.

Leaving them directly in the code, in a Git repository, or in a shared file is therefore a very bad idea.

OWASP recommends using a dedicated secrets management solution and specifies that secrets must not be embedded directly in source code or build artifacts.

This is even more critical with the rise of automation and AI tools.

A business application is no longer an isolated block.

It is often at the center of ten other services.

An application’s security therefore also depends on the security of all its connections.

Rapid development must not mean improvised production.

AI has significantly accelerated development.

It is now possible to generate an interface in minutes and have a functional first application in days.

This is a positive evolution.

But it also creates a risk: confusing development speed with production maturity.

A prototype can work with minimal oversight.

An application used daily by 100 employees cannot follow the same rules.

Once an application handles customer data, HR information, contracts, financial records, or confidential documents, the level of requirement must change.

This is also why our approach to custom application development includes defining security and GDPR constraints, followed by testing and a security audit before deployment.

The goal is not to turn every SME into a bank.

The goal is to align security with the actual risk.

Legacy internal software also deserves your attention

It would be easy to assume the issue only affects new applications built too quickly.

It’s not.

Another major risk area often lies in older tools.

A PHP application developed fifteen years ago.

A heavily customized ERP.

An old Access database.

A server no one dares restart.

A business application whose original developer has left.

These systems may hold some of the company’s most critical data.

They were also sometimes designed at a time when usage patterns were very different.

Less remote work.

Fewer APIs.

Fewer connections to external services.

Less data accessible from the internet.

Maintaining these tools without ever reassessing their architecture can become a problem.

The answer isn’t necessarily to discard everything.

A gradual modernization of legacy IT systems can help regain control without disrupting operations.

Where are your company’s data really stored?

Application security ultimately raises a simple question: do you know exactly where your data flows?

Many SMEs now rely on a stack of services.

The application sends data to an automation.

The automation forwards it to a CRM.

The CRM triggers an email.

Part of the content is then processed by an AI API.

A document is stored elsewhere.

Each tool may seem under control individually.

But the whole becomes harder to track.

This is why digital sovereignty for SMEs is also a security concern.

It doesn’t necessarily mean self-hosting everything.

It means knowing which components are critical, where data resides, which providers can access it, and how to retrieve everything if a platform becomes unsuitable.

A company unaware of its digital architecture will struggle to assess its real exposure.

GDPR also comes into play after an incident

A data breach is not just a technical issue.

When a personal data breach poses a risk to individuals’ rights and freedoms, the data controller must document and report it to the competent authority without undue delay—within 72 hours of becoming aware, where GDPR conditions apply.

If the risk is high, the affected individuals must also be informed, unless exceptions under the regulation apply.

This also changes how applications are designed.

After an incident, the company must be able to determine what was affected.

Which data?

Which users?

For how long?

Through which access?

With what possible consequences?

Without logs, data mapping, or a clear architecture, answering these questions quickly becomes very difficult.

What the tax authority breach should really remind businesses

The DGFiP incident will likely continue to make headlines as investigations progress.

But for businesses, the key takeaway is already clear.

Cybersecurity is not just about firewalls or passwords.

It is a global property of the application.

It depends on its architecture, roles, access controls, database, APIs, secrets, logs, and how it is maintained.

Above all, security must evolve with the application.

The almost-empty internal tool created two years ago may no longer be just a small tool today.

It may now handle your clients.

Your operations.

Your documents.

Your billing.

Or part of your know-how.

At this stage, continuing to treat it as a prototype becomes risky.

A robust application is also built on these choices

At Scroll, we develop and take over business applications, SaaS, and internal tools.

Speed remains important.

We use AI and modern stacks precisely to move faster.

But a production-bound application must also remain manageable.

This requires a clear architecture, appropriate permissions, serious access and secret management, separate environments, backups, testing, and a thorough approach to sensitive data.

The goal is not to make every project heavier.

The goal is to prevent a tool that has become critical from still relying on the choices made when it was just a prototype.

If you have an internal application, a SaaS, or a no-code tool that has become central to your business, Scroll can audit the existing system and design a bespoke application with a security level tailored to your data and usage.