Rising security incidents: intrusion prevention and damage minimization in web systems

Since the start of 2026, and especially in recent months, reports of unauthorized access and data breaches targeting domestic corporate web systems have been increasing.
On October 8, JPCERT/CC released a "Notice Regarding Recent Unauthorized Access Incidents at Domestic Organizations," and on the following day, IPA also called for emergency measures in response to information leakage caused by unauthorized access.

When looking at these incidents, attention tends to focus on the problems of legacy systems and outdated software.
Of course, those represent significant risks, but it's not as simple as saying that upgrading your system will guarantee security.

It's important to thoroughly implement measures to prevent intrusions before they occur, and even if a security issue does arise despite those efforts, a multi-layered defense design that minimizes damage is essential.

This time, we examined future web security by looking at Cloudflare, Supabase, and EmDash, which was officially released in September 2026.

Unauthorized access targets are not limited to specific companies

What JPCERT/CC highlighted in this notice is not limited to attacks exploiting known vulnerabilities. Attack methods are diverse, ranging from searches for configuration files and backup files, unauthorized API requests, and misuse of stolen API keys, to lateral movement using publicly accessible web servers as a foothold.

Particularly concerning is that in addition to services for general users, administrative systems and BI tools for employees have also become targets of attacks.
With the advancement of AI, the old concept of "just don't get indexed by Google" has disappeared; any system exposed on the internet now faces the constant risk of automated reconnaissance and attacks on a daily basis.

The idea that "a small system like ours won't be targeted" no longer holds true.

Does using modern technology guarantee security?

Outdated PHP, frameworks that have reached end-of-life, and CMSs that haven't been updated in years naturally carry risk.
But is it safe if we build with Next.js or Astro and use cloud services?

Unfortunately, not necessarily. 😭

Vulnerabilities can be discovered even in the latest frameworks, and if there are flaws in API authorization logic, there's a risk of accessing data that shouldn't be accessible.
If authentication credentials or API keys are mismanaged, even robust cloud services can be compromised, so having new technology and having a secure system are separate matters.

Place defensive layers in front of your application with Cloudflare

Cloudflare is known as a CDN, but it also plays an important role in securing web applications.
For example, you can detect and block suspicious requests with a WAF (Web Application Firewall), suppress high-volume traffic with rate limiting, and use Cloudflare Access to restrict access to admin dashboards and internal tools to authenticated users only.

That said, it's not perfect at all. 😭
The fundamental risk lies in making admin screens that shouldn't be publicly accessible available to anyone.

A WAF can't prevent all attacks—misuse of properly formatted requests and application-specific authorization flaws require separate safeguards.
Cloudflare is a system that places defensive layers in front of your application, not a guarantee of the application's own security.

Control access at the database level with Supabase

This is where RLS (Row Level Security), available in Supabase, becomes important.
RLS is a PostgreSQL feature that lets you control data access at the row level, so for example in a multi-tenant business system, you can set rules in the database so that Company A's users can only see Company A's data.
Even if there's an error in the application's authorization logic, properly configured RLS acts as an additional layer of defense.

But…RLS isn't a silver bullet either. 😭

Supabase's secret key and traditional service_role key carry strong permissions that can bypass RLS depending on how they're used, so if management is mishandled, the protection provided by RLS breaks down.
Table permission settings and policy testing are equally essential.

What matters is not relying solely on application-level authorization, but giving the database independent control as well.

EmDash's approach: don't trust plugins by default

On September 28, 2026, "EmDash 1.0," a CMS developed with support from Cloudflare, was released, along with its official plugin registry!
We've been following it since launch and have already implemented sites with it, so it feels quite meaningful to us.

Building a multilingual blog with EmDash — reducing translation API costs even with SSR
Migrating from microCMS to EmDash + Cloudflare

What's interesting about EmDash is its plugin security model.
In traditional CMSs, plugins often run with permissions similar to the CMS core, and plugin vulnerabilities can compromise the entire system. However, plugins deployed from EmDash's official registry run inside a sandbox.
By limiting what functionality and resources plugins can access and making required permissions explicit, the design minimizes the blast radius.

Of course, EmDash does have native plugins that don't use the sandbox, so not all plugins are safe. EmDash itself is also a relatively new CMS, and we need to monitor its operational track record and security response going forward.

Still, the design philosophy of not trusting plugins from the outset is a noteworthy point when thinking about future CMSs.

What they share is the principle of "trusting nothing by default"

Cloudflare, Supabase, and EmDash are services with different roles, but from a security perspective they share a common philosophy.

• Cloudflare: Control suspicious access before it reaches your application
• Supabase: Enforce permission controls at the database level, even for access from your application
• EmDash: Isolate plugin execution environments without granting unnecessary permissions

Each of these approaches reflects the same principle: rather than placing all trust in a single mechanism, limit trust to a defined scope. This aligns with zero-trust architecture and the principle of least privilege.

• Even if authentication is compromised, not all operations are permitted.
• Even if an API has flaws, not all data can be retrieved.
• Even if a plugin contains a vulnerability, the entire system cannot be compromised.

By establishing these boundaries, you reduce the risk that a single issue cascades into system-wide damage.

Summary: Prevent intrusion and contain the blast radius

Switched to React! Moved to Next.js! Migrated to the cloud!
These technology upgrades matter, but replacing frameworks or infrastructure alone is not enough for true modernization. What matters is clarifying the responsibilities and permissions across authentication, authorization, APIs, databases, and external services, and building a structure where a breach in one area is less likely to spread to others.

There is no absolute security.
This is precisely why we must layer multiple preventive measures to block intrusions before they occur, and design multi-layered defense systems that can minimize damage even if problems do arise.

Cloudflare, Supabase, and EmDash are not all-purpose solutions, but these technologies provide mechanisms to grant only the necessary permissions and establish boundaries based on roles.

In building web systems, Liberogic prioritizes not just adopting the latest technologies, but also responsibility separation and multi-layered defense.

With security incidents occurring with increasing frequency, when considering modernization of web systems, it's important to look not only at what technologies to use, but also at how much trust is built into the design.