Luckily, or maybe not, everything has changed. I actually wrote how AI will become the core part of the websites we use every day, and that made me realize that learning about AI security is not only interesting, but will likely become the most important skill in the near future for security professionals.

If you come from the AppSec world like me, you will probably notice that many things feel familiar. There are more similarities with traditional applications than you might expect, even though the fundamentals are different. This actually makes getting started much easier, so I definitely encourage you to start exploring right now.

Fuzzing is not a new concept at all, but for some reason it confused me for quite a while because I kept mixing it up with brute force attacks. I was never sure where the line between them was, until I found definitions that finally made it click for me:

• Brute force is a trial-and-error technique where an automated process tries many possible combinations in the hope of eventually guessing the correct one, for example to crack passwords, secrets, or encryption keys.

• Fuzzing, on the other hand, is a testing technique where random, malformed, or unexpected inputs are sent to an application in order to discover bugs, crashes, or vulnerabilities.

When we bring this idea into the LLMs context, fuzzing means automatically generating large volumes of unexpected, malformed, or adversarial inputs to reveal weaknesses in the model.

Running a fuzzing test as part of a CI/CD pipeline makes a lot of sense. The goal is simple: find the problems before attackers do, and harden the model against things like prompt injection, data exfiltration, unsafe outputs, or misalignment. And that is exactly what the GitHub repository that I am introducing in this post is all about.

The goal of this project is to demonstrate how fuzzing can be applied to an ADK LLM-based agent, while fully automating the process through a GitLab CI/CD pipeline and deploying the target agent on Google Cloud using Pulumi.

In this example, I use FuzzyAI to generate adversarial prompts designed to jailbreak the agent, extract sensitive information, or bypass its safety controls. The responses are then evaluated using GPT-4o as a classifier, which determines whether the model behavior should be considered unsafe or policy-violating.

This is the pipeline job definition:

fuzzyai_jailbreak_scan:
  stage: fuzz
  image: python:3.12
  needs:
    - job: deploy
  variables:
    FUZZYAI_TARGET_URL: "$OLLAMA_BACKEND_URL"
    FUZZYAI_HTTP_METHOD: "POST"
  before_script:
    - cd fuzzyai
    - pip install git+https://github.com/cyberark/FuzzyAI.git@8184b96
  script:
    - fuzzyai fuzz -C config.json -e host="$(echo "$OLLAMA_BACKEND_URL" | sed -E 's|https?://||')"
    - python scripts/fuzzyai_to_gitlab_dast.py results/*/report.json gl-dast-report.json
  artifacts:
    when: always
    paths:
      - fuzzyai/gl-dast-report.json
    reports:
      dast: fuzzyai/gl-dast-report.json

To integrate the results into the security pipeline, I added a simple script, called fuzzyai_to_gitlab_dast.py, that converts the findings produced by FuzzyAI into a format compatible with GitLab DAST reports. This allows all detected issues to be automatically collected and displayed in the GitLab Vulnerability Report dashboard, making LLM security testing part of the standard DevSecOps workflow.

And the result is pretty interesting. The fuzzing process actually managed to jailbreak the LLM, and the pipeline reported it as a critical vulnerability in GitLab:

Here is the repository if you want to explore the full codebase:

👉 GitHub Link: Fuzzing-ADK-Agent-via-GitLab-pipeline

Pretty straightforward, and probably easier than you expected, right?

I definitely want to keep experimenting with ways to automate security testing for AI models, but right now I am not sure which areas are the most relevant to explore next. Any ideas in mind? I would love to hear them and consider trying them out.

Thanks for reading this post!

AI has the potential to move websites beyond predefined content toward understanding intent, reasoning over context, and acting on the user’s behalf. With that in mind, here’s how I believe websites will change over the next few years.

1. From pages to interfaces

Websites today are mostly collections of pages you navigate. In the future, many sites will behave more like adaptive interfaces.

• Fewer menus, more conversations.

• You don’t browse, you ask.

• The “homepage” becomes an intelligent entry point, not a layout.

Example:

Instead of navigating listings on Booking, you say:

“Plan a 5-day trip to Japan in April with food and nature focus.”

The site then builds the experience on demand.

2. AI becomes the primary user interface

Search boxes, filters, and FAQs will fade into the background.

AI agents act as:

• Sales reps.

• Customer support.

• Personal assistants.

Each user gets a customized site behavior, not just personalized content.

Two people visiting the same website may effectively see different websites, optimized for:

• Their goals.

• Their skill level.

• Their past behavior.

• Their preferred interaction style (chat, voice, visual).

Example:

Instead of searching and filtering on Amazon, you say:

“I need everything for a small gaming setup under a $500 budget.”

The online marketplace then selects, explains, and prepares everything in one flow.

3. Websites become goal-driven, not content-driven

Right now, websites present information. Future websites will execute outcomes.

Instead of:

• “Here’s our documentation”.

• “Here’s our pricing page”.

You get:

• “What are you trying to do?”.

• “Let me handle that for you”.

The site becomes a tool, not a brochure.

Example:

Instead of reading accounting documentation or setup guides, Holded lets users say:

“Help me set up my freelance business, track income and expenses, and prepare my tax reports”

And then walks them through the required steps, automates bookkeeping, and generates the necessary filings and summaries.

4. Less navigation, more orchestration

Traditional UI elements will shrink in importance:

• Mega menus.

• Deep page hierarchies.

• Manual form filling.

AI will:

• Auto-fill.

• Auto-decide defaults.

• Auto-connect external services.

The website becomes an orchestrator between APIs, data, and user intent.

Example:

Instead of reading instructions and filling forms, a user gives permission once on Stripe, and the platform gathers the required business data, auto-fills onboarding details, connects payments and tax services, and completes setup without repeated manual steps.

5. Trust, identity, and verification matter more

As AI-generated content explodes, the value of a website shifts from content to credibility.

Expect:

• Stronger identity verification.

• Proof of authenticity (human-verified, source-backed).

• Transparent AI behavior (“why this answer was generated”).

Websites will need to earn trust, not just attention.

Example:

Platforms like Wikipedia clearly show which parts of an article were AI-assisted, which were reviewed by humans, and provide verified source trails instead of presenting raw text alone.

6. Performance shifts from speed to intelligence

Today we optimize:

• Load time.

• Accessibility.

• SEO / GEO.

Tomorrow we optimize:

• Quality of AI reasoning.

• Context awareness.

• Memory across sessions.

• Ethical and safe responses.

A “slow” site that gives the right answer may outperform a fast site that forces users to think.

Example:

Instead of fast-loading rows, Netflix asks:

“Do you want something light, intense, or comforting tonight?”

And gives one strong recommendation with reasoning and stored preferences.

7. Developers design systems, not pages

Web development will change significantly.

Less hand-crafted UI logic.

And more:

• Prompt design.

• AI behavior constraints.

• Data pipelines.

• Feedback loops.

Frontend will no longer be what users see, but how AI represents choices to them.

Example:

Instead of static search result pages, Skyscanner interprets travel intent, analyzes live price and availability signals, surfaces trade-offs between cost, time, and convenience, and suggests next best options dynamically as conditions change.

8. The web becomes more fragmented, and more personal

Ironically, while AI unifies interfaces, it fragments experiences:

• Each user’s web feels unique.

• Fewer shared “common” pages.

• More private, ephemeral interactions.

This may reduce viral pages, but increase deep engagement.

Example:

LinkedIn presents differently user’s profile data depending on whether the viewer is a recruiter, founder, or investor, tailoring what’s shown based on their interests, even though everyone is using the same site.

A short way to summarize

1. Past: websites showed information.

2. Present: websites guide users.

3. Future: websites think and act with users.

The biggest shift isn’t visual, it’s philosophical:

Websites stop asking “What do we want to show?” and start asking “What does this person want to accomplish?”

This transformation redefines the web from a collection of pages into a set of intelligent systems designed to help people achieve outcomes, not just consume content.

Does this resonate with you? I’d love to hear your thoughts.

But concepts are just theory, and being pragmatic in security is extremely important, since real constraints become only visible when trying to reach the desired security state and technology limitations usually remain hidden during the design phase. These constraints eventually require adjustments to the original plan, and a practical approach is the only way to uncover these realities before altering the direction of a project.

From this standpoint, and to make these ideas tangible and understandable, a public repository has been created that implements a minimal application deployed through a fully automated CI/CD pipeline, defining different runtime environments and integrating real security controls such as SCA, SAST, IaC scanning, Secret Detection, and DAST. It also includes all instructions needed to recreate it within your own setup.

The project is intentionally simple, but the pipeline is intentionally complete. It demonstrates what a developer-friendly, security-aligned software delivery looks like, and more importantly, it illustrates how much easier security becomes when the SDLC is predictable, automated, and grounded in clear environment definitions.

Let’s break it down.

A Minimal Notes API… with Maximum Security Visibility

The application itself is deliberately uncomplicated: a small Express.js REST API with two endpoints:

• POST /notes — create a note

• GET /notes — list existing notes

There is no authentication, no validation, and intentionally no protections.
Why?
Because the objective is not the app, it’s the pipeline.

The code is built to reveal:

• How insecure defaults become evident when placed within a CI/CD process.

• How GitLab detects vulnerabilities at multiple layers.

• How cloud-native deployments can be automated securely.

• How clearly defined environments shape your security posture.

It may be viewed as a “Hello World” for DevSecOps foundations.

The Architecture: Small App, Real Deployment Model

The repository deploys the application to Google Cloud Run, fully orchestrated through Pulumi, using GitLab CI/CD as the automation engine.

It includes:

• Three isolated environments:
  dev, stage, prod — each on their own GCP project.

• Dedicated service accounts per environment for deployment.

• A separate identity for DAST, so staging remains locked down.

• Environment-specific configuration and seeding behaviour:

  • dev: purged + seeded on each deploy.

  • stage: seeded but existing data preserved.

  • prod: never seeded, to protect real production data.

These decisions mirror the environment definitions explained in the latest post:
different expectations → different permissions → different controls.

This is precisely what healthy RTEs look like.

How the Delivery Flow Is Intended to Operate

The repository suggests a simple, clean, and predictable workflow:

feature/* → dev → main → prod

Each branch moves the application through the SDLC:

• Commits to dev deploy to the development environment.

• Merging into main deploys to staging environment and runs DAST.

• Merging into prod deploys to production environment.

Static scans run on every branch and MR to provide early feedback. However, since main is the default branch, it is the only one whose scan results appear in the GitLab Vulnerability Report Dashboard.

The main branch serves as the central and stable source of truth for the project.

Security Scans Integrated End-to-End

The following GitLab security analyzers run automatically:

• SCA (Dependency Scanning): identifies vulnerable third-party libraries.

• Secret Detection: uncovers exposed tokens and sensitive credentials.

• SAST (Semgrep): detects insecure coding patterns within the source code.

• IaC Scanning (KICS): flags misconfigurations in Pulumi and other infrastructure definitions.

• DAST (API Security): performs live security testing against the running service in staging.

This gives a multi-layered view of risk across:

• The codebase.

• The dependencies.

• The infrastructure.

• The running service.

All without requiring developer intervention and operating as non-blocking stages within the software delivery process.

Security becomes frictionless once pipelines do the heavy lifting.

Access Control: IAM as a Security Boundary

One of the most important aspects of this repo is how access to each environment is controlled:

• dev: intentionally unreachable (reserved for internal developers access).

• stage: only reachable by the GitLab DAST service account (also reserved for internal developers access).

• prod: publicly accessible.

This is a practical example of how you can use IAM-based access restrictions to enforce clear separation of concerns in the SDLC.

Most security incidents don’t occur because encryption was missing or because a fancy system wasn’t configured correctly, they happen because access control boundaries were blurry.

⚠️ According to the recent OWASP 2025 release, Broken Access Control remains positioned as the highest-ranked vulnerability group.

The Purpose Behind This Repo

This project is not just a template, it can serve as a practical reference.

It shows how defining runtime environments clearly, and aligning CI/CD logic with those definitions, naturally reduces the friction of applying security controls.

It also demonstrates how:

• access boundaries

• identity separation

• predictable configurations

• automation

• and environment isolation

…all contribute to making security scalable rather than painful.

Because security isn’t just about adding scanners. It’s about creating the right conditions for security to flourish.

Explore the Repository

I encourage you to take a closer look at the repository:

👉 GitHub Link: Notes-App-with-GitLab-SCA-SAST-and-DAST

Fork it, clone it, run it locally, inspect the pipeline, review the Pulumi code, and break it freely. It’s built for your own experimentation.

🍪 Thanks for Reading The Secure Cookie

If you are enjoying these contributions to real-world application security, consider subscribing or sharing it with someone who might benefit. And if you are into great security reads, I just picked up the book 📖 Alice and Bob Learn Secure Coding by Tanya Janca, and I can honestly recommend diving into it.

See you in the arena, gladiators!

Interpretation shapes perception, and the same principle applies to security in organizations, which is far from an exact science. Security embodies a broad spectrum of colours, and each company must choose the one that best reflects its character. It stands as a cultural mindset that extends from leadership to every team, influenced by both executive and technical management.

Sometimes, raising security levels requires making decisions that change how teams operate, and this is where that mindset becomes essential. Since technology evolves continuously, security does as well, although its changes are not inherently negative. They may demand an initial effort, but they can pay off in the long run. However, to recognise their value, it’s essential to maintain a clear vision and understand what lies beyond the immediate effort.

To put it in practical terms, today it's far easier to integrate security into applications when there is a complete SDLC fully automated within a CI/CD pipeline. A few years ago, the idea of creating a streamlined pipeline to enhance security might not have been viewed as practical, but now it’s a game changer. The reason is simple: strong and effective security checks can be seamlessly integrated, and teams that still rely on manual or fragmented workflows find it much harder to embed security, resulting in slower and less efficient delivery processes. Plus, looking ahead, AI will increasingly contribute to add and govern more of these controls.

That’s why I am drawn to organisations that treat security not as a checklist but as a core element of their identity, being taken into account in every decision from architecture to delivery. I had to defend security projects when the vision wasn’t shared at all, and despite much persistence, it was only on rare occasions that I saw a leader’s opinion shift. It was very frustrating for me. I found it extremely hard to change someone’s mind when security is seen as necessary but just a little more than costly and irritating, a colour I would not choose from the spectrum mentioned before.

Entering the technical section of this post, it’s important to notice that the key is not how many environments are defined or how they are named and used within the SDLC, but what is expected from each and which actions are permitted or restricted. These are simply my references based on my experience, which I hope you find descriptive and useful.

Understanding RTEs

A runtime environment is the space where a program or application runs, considering both the hardware and software infrastructure required for executing the code in real-time.

In DevOps, runtime environments encompass all infrastructure and configurations involved in executing applications throughout their entire lifecycle. These environments typically include development, test, staging, and production environments, each serving a specific purpose in the software delivery pipeline:

Managing and maintaining consistent and reliable runtime environments is crucial for ensuring the security, stability, scalability, and performance of applications as they progress from development to deployment serving end users.

Development Environment

The development environment is the first environment in software development which acts as the workspace for developers to do programming and other operations related to the creation of software. It covers from the first lines of code to all code updates. As the name suggests, this is where the development of the software takes place.

Part of the development environment also includes the Integrated Development Environment (IDE), which is a software package with extensive functions for authoring, building, testing, and debugging a program that is commonly used by software developers running on its own workstation. Common IDEs are Visual Studio Code, IntelliJ IDEA, Cursor, etc.

Test Environment

A test environment allows testing engineers to analyse new and changed code whether via automated or non-automated techniques. Using tests environment testers make sure that the new code will not have any impact on the existing functionality. They also ensure the quality of the code by finding any bugs and reviewing all bug fixes.

The primary focus here is testing individual components rather than the entire application, aiming to verify compatibility between old and new code. Different types of testing suggest different types of test environments, some or all of which may be virtualized to allow rapid, parallel testing to take place.

Staging Environment

A staging or pre-production environment is a nearly exact replica of the production environment, aiming to closely mirror the actual production environment to ensure the software works correctly.

The focus here is to test the application or software as a whole. This is where you can conduct deep tests to ensure that no problems come up in production and limit negative impact on users. Another key purpose of staging is performance testing, especially load testing, since it is often highly sensitive to environmental factors.

Depending on any regulatory factors (such as GDPR requirements) and the organization’s level of ability to anonymize data, a staging environment may include not only fake but also anonymized or complete sets of production data to closely replicate the real-world production environment.

Access to the staging environment is often limited to a small group of individuals. Only those with whitelisted emails or specific network addresses, along with the developer team, have access the application in staging.

Isolating the staging and production environments on two separate clusters and VPCs is a good practice to avoid any potential issues on production caused by the staging environment. This is not a mandatory step, but it is well recommended.

How to create a Staging Environment

• Create a staging environment from scratch.

• Clone the production environment and create a staging environment from it.

What is the difference between Test Environment and Staging Environment

The main difference between a staging environment and a testing environment is the level of similarities to the production environment.

In a staging environment, every element is updated to the latest version, closely reflecting the live site except for the changes recently pushed to the development environment. This configuration ensures that new changes are tested thoroughly to avoid unexpected disruptions when deployed to the production environment.

In a testing environment, there isn’t a strict need to update every element to match the production environment. Testing here is more targeted, focusing on specific code changes rather than a full system test, and it operates on assumptions about how other parts of the system function. This approach speeds up the testing process, as there’s no requirement to fully replicate the production setup, unlike in a staging environment.

Production Environment

A production or live environment is where it runs on a production instance and is officially available to real users.

When deploying a new release to production, rather than immediately deploying to all users, the release should be deployed in phases to a segment of users first to see how it performs to catch and fix any additional bugs before deploying to the rest of the users.

Showing How This Works in Practice

To make it easier to understand the purpose of environment definitions, I created a Git repository with a minimal web application configured under a CI/CD pipeline, on GitLab, for automatic deployment to Google Cloud. It will later integrate SCA, SAST, and DAST security practices in the following upcoming posts.

👉 This is the link to the repository.

I encourage you to take a closer look. Let’s bring things to the arena, gladiators!

Reading Picks

Here are a few articles I found valuable in recent weeks:

• The GRC Engineer’s Toolkit - How To Turn Compliance Into Code by

• Success = (number of attempts) × (probability of success each time) by

• 📖 I just bought the book Alice and Bob Learn Secure Coding! by Tanya Janca.

This is the final piece of the puzzle in our journey to secure file uploads. After covering file name sanitization, file type validation, and file content inspection, the focus now shifts to ensuring the upload infrastructure itself is secure through robust resource limit management and strict permissions/access controls.

Why Resource Limits Matter

Even perfectly validated files can become a problem when there are no boundaries. Attackers don’t always need to exploit a vulnerability, sometimes they just need scale:

• Oversized files can exhaust resources, such as RAM or CPU, degrading performance and availability. Attackers may repeatedly upload them to overwhelm system resources.

• Heavy uploads can consume bandwidth, affecting network performance for legitimate users.

• Numerous files can complicate storage management, increasing maintenance needs and making backups and recovery processes slower and more error-prone.

When applications allow users to upload without limits, two key risks emerge:

• Denial of Service (DoS): flooding a system with excessive or oversized uploads can exhaust available resources instead of exploiting a weakness.

• Cost spikes: on cloud platforms that bill by storage, bandwidth, or processing time, a few malicious users can quickly generate massive expenses.

Resource Limit Management

Effective resource limit management requires enforcing technical controls over the size of files, the total number of files a user can upload, and the rate of upload and download requests.

File Size Limits

Every upload endpoint should enforce a maximum file size. Without this control, an oversized file can freeze your app while it tries to process or store it.

A simple way to handle this in Node.js is with multer, which supports size limits natively:

const multer = require(”multer”);

const upload = multer({
  ...
  limits: { fileSize: 5 * 1024 * 1024 } // 5 MB
});

When users exceed this size, the request is automatically rejected, keeping memory and disk usage predictable.

Beyond security, size limits also help protect user experience by preventing long upload times and reducing failures in slow connections.

💡 Tip: Define limits based on your actual business needs.

Total Upload Limits

Restricting the size of a single file is not enough. An attacker could automate uploads of countless small files, eventually filling up your storage and degrading system performance. Even if each upload is small and passes validation, the cumulative effect can overwhelm storage, backups, and indexing processes.

A reliable method is to also monitor the number of uploads or the total storage space consumed by each user. When either threshold is reached, the application should temporarily block new uploads until space is freed or the quota is increased. This approach enforces fair resource usage across users, prevents storage abuse, and helps maintain long-term system reliability.

Upload and Download Rate Limiting

Rate limiting is a necessary measure that imposes restrictions on the number of upload and download requests a user can make within a short period to prevent excessive data transfers. This control helps prevent any single user from flooding the system with numerous requests, which is crucial for mitigating Denial of Service (DoS) attacks.

Here is a simple Express example using the express-rate-limit npm package to control the number of uploads allowed per time window:

const { rateLimit } = require(”express-rate-limit”);

const uploadLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes window
  max: 100, // Limit each IP to 100 requests per windowMs
  message: “Too many uploads, please wait a bit.”
});

app.post(”/upload”, uploadLimiter, (req, res) => {
  // File upload logic here
});

Whenever authentication is available, base rate limits on the user’s session rather than on IP addresses. Also note that the IP received by the application often belongs to an intermediary element in the infrastructure rather than the actual client.

File Storage Location

Before setting up uploads, it’s important to decide where the files will live. The storage location directly impacts both security and performance.

Using a third-party storage service such as Google Cloud Storage is often the preferred option. These services typically come with robust, industry-standard security features, including encryption (both at rest and in transit), secure APIs, role-based access control (RBAC), automated updates, built-in redundancy, detailed audit logs, and compliance with various regulations like GDPR, HIPAA, or SOC2.

When a third-party service is not an option, consider deploying a dedicated server for file storage, isolated from the main web application. This approach provides complete segregation of duties between the application handling user interactions and upload requests from the server managing file storage, thereby reducing the impact of potential vulnerabilities.

If neither a storage service nor a separate server is possible and files must reside on the same host, make sure they are placed outside the webroot directory to prevent direct web access and reduce exploitation risk.

Permissions and Access Control

Once files are stored, the next question is: who can access them?

Regardless of whether files are kept in cloud object storage or on a self-hosted server, the same principle applies: only authorized users should be able to upload, view, or download them.

Authenticate and Authorize Every Action

When users are permitted to upload files, ensure they can only:

• Access their own uploaded content.

• Retrieve files via validated application endpoints, not through direct public URLs.

Even when files are stored in a managed service such as Google Cloud Storage, all access should be managed through your web application, where authorisation, validation, and logging can take place.

A common mistake is serving files from a publicly accessible path, for instance:

• A local web server directory like /uploads/.

• Or an open storage bucket such as https://storage.googleapis.com/my-bucket/uploads/...

If filenames are predictable, attackers can easily enumerate and retrieve private files.

Instead of exposing direct storage URLs, use an internal handler in your backend to control all file access. This handler acts as a controlled gateway that verifies permissions, logs access, and only then issues a temporary signed URL for the user to download the file.

This design ensures that every download request is authenticated, authorised, and traceable, while the underlying storage such as Google Cloud Storage remains private and isolated from public exposure:

const { Storage } = require(”@google-cloud/storage”);
const storage = new Storage();
const bucket = storage.bucket(”my-secure-bucket”);

app.get(”/download/:id”, authMiddleware, async (req, res) => {
  const file = await db.getFile(req.params.id);

  if (!file || file.ownerId !== req.user.id) {
    res.status(403).json({ message: “Forbidden” });
    return;
  }

  // Generate a signed URL valid for 2 minutes
  const [url] = await bucket.file(file.storedName).getSignedUrl({
    version: “v4”,
    action: “read”,
    expires: Date.now() + 2 * 60 * 1000,
  });

  res.json({ downloadUrl: url });
});

In this pattern, the /download/:id route functions as the internal handler. It performs authentication through middleware, enforces authorisation by verifying file ownership, and generates a short-lived signed URL to provide secure, time-limited access.

This approach keeps files private within the storage service while users access them safely through verifiable and expiring links that do not reveal internal bucket paths or filenames.

💡 Tip: When using signed URLs, keep expiration times short and include user or session identifiers in logs.

Keep Filesystem Permissions Tight

When files are stored on a regular server such as a Linux host or a self-managed instance, permissions become a critical layer of defence. Properly configured filesystem permissions help ensure that uploaded files cannot be executed or accessed by unauthorised users, even if a vulnerability exists elsewhere in the application.

Uploaded files should never be granted execute permissions. In most cases, the application process only needs to read and write files like images, documents, or logs. Executing them should be strictly disallowed.

Additionally, not every file needs both read and write permissions. For instance, if the application only writes files that are later processed or archived, write-only permissions can further reduce the attack surface.

Equally important, ownership of the upload directory should also be limited to the non-privileged user running the application (for example, nodeapp), preventing other system accounts from accessing or modifying those files:

sudo mkdir -p /srv/uploads
sudo chown nodeapp:nodeapp /srv/uploads
sudo chmod 700 /srv/uploads

This configuration ensures that only the application user can read or write to the directory and that no one can execute files within it.

Reading Picks

Here are a few articles I found valuable in recent weeks:

• Hacking JWTs: A Practical Guide by

• What to do before refactoring by

• To Cache or Not to Cache by

• Cognitive load is what matters by Artem Zakirullin

It’s been an incredible journey of learning and growth. I’ve met so many people, made great friends, and most importantly, noticed a big difference in professional happiness. Most people living permanently in Europe, when I ask them how they feel about their jobs, usually answer, “I’m doing okay”. But when I ask digital nomads the same question, their answers are often filled with enthusiasm, “I’m really happy with it.”

And you know what? They’re often doing pretty similar tech jobs.

I realized that what truly makes the difference is perspective, not the job itself, but the perspective of working with the freedom to shape your own lifestyle. It’s a completely different mindset when your job becomes the key that enables you to live the life you want.

For many digital nomads I know, including myself, work becomes our only real responsibility while abroad. When we travel to live and work in other countries, we fortunately leave behind most daily chores, such as grocery shopping, cooking, washing dishes or clothes, running errands, cleaning the house, or repairing things, because we can usually find affordable services that handle those tasks for us. Our main focus becomes our work. The rest of your day is open for you to spend however you like.

That’s where the motivation comes from. Your tech job becomes the source of this upgraded lifestyle. Everything you enjoy is made possible by the European income you earn from it. You don’t want to lose that; in fact, quite the opposite, you want to be productive. You want to complete your projects, support your colleagues, and make both clients and managers happy, because your personal happiness directly depends on the quality of your work. That’s why I’ve seen so many digital nomads approach their jobs with such strong motivation.

I’ve been to tropical coworking spaces that were quiet as a tomb, yet felt like they had two completely different sides. I was even shocked at first, everyone was deeply focused, working hard, barely talking. I thought they just weren’t social. But later, at social events, I realized people were friendly, open, and eager to connect. It wasn’t that they were antisocial, but they simply were taking their work seriously. Honestly, I’ve never experienced such a productive atmosphere in any traditional office that I’ve been.

Now, I’m not saying everyone in your company should start digital nomading. Of course, some people can’t do it, others simply wouldn’t enjoy it, and human connection remains essential, particularly when it comes to teamwork and building strong relationships. Face-to-face interaction helps people bond and collaborate better. There’s no doubt about that. So, in my opinion, the key for any company is to find the right balance.

And by balance, I don’t mean a “three days in the office, two days at home” policy. That’s not the kind of remote work I’m talking about, it barely changes the work experience and fails to provide the real advantages of what I mentioned. I’m referring to allowing people to relocate for two or three months to experience a different lifestyle and explore different routines.

So what do you think? Could letting people work abroad for a couple of months a year make them happier and more motivated, or do you think it would cause more challenges than benefits? I’d love to hear your thoughts.

Reading Picks

Here are a few articles I found valuable in recent weeks:

• The Simple Habit That Lowers Stress, Boosts Energy, and Improves Health by

• How to multiply your Hapiness by

• 12 rules to change your life in 12 months by

File type validation won’t tell you whether a file is what it claims to be, as it can be easily spoofed through misleading extensions, manipulated magic number signatures, or altered headers. A valid approach to determine what kind of file we are dealing with is to inspect the file’s actual content and make decisions based on that analysis. However, implementing such a process as a developer introduces multiple security considerations and becomes infeasible, being complex, time-consuming, and often unreliable.

The most effective path is to rely on dedicated platforms that offer specialised capabilities for file analysis, such as VirusTotal. They provide an easier and straightforward solution for file content validation, but this immediately raises a recurring concern for organizations: [more] subscription costs.

To be honest, subscription cost challenges are something I often see among companies in Spain. Even though many SaaS platforms and service providers claim to offer competitive prices across Europe, these conditions may not always apply to the southern regions, where available budgets are often lower compared with companies located in northern territories.

As a result, many engineers I’ve worked with tend to look for the cheapest or free option available, which managers often approve to move forward. Still, file content validation must be handled carefully, as it it may result in false trust or sensitive data being exposed. For example, when using the VirusTotal platform without a paid subscription, any file you upload can be accessed by subscribed users, which obviously it’s a red flag.

This is where the real challenge begins. The company chooses not to invest in a specialized service, yet still expects you to deliver a robust implementation for file content validation.

Even though it is far from my preferred approach, there is an alternative that can still be applied to move closer to the goal. Keep in mind that simplicity will be crucial in this scenario, because if the process is not straightforward, developers will struggle, introduce errors, and may choose not to adopt it widely.

A pragmatic solution is: to adapt the existing WAF in the infrastructure into a basic file content validation tool by adding a lightweight application that offers a graphical interface, an API endpoint, or both, enabling users and other corporate applications to use it as a specialized service.

Several Web Application Firewalls (WAFs) incorporate file malware detection features in their file upload protection or content scanning modules that could be leveraged to satisfy the file content validation requirements. These modules may offer limited functionality compared to specialized services like VirusTotal, but this approach can demonstrate value gradually and eventually help convince management to finally adopt a full professional service.

Cloud-based WAFs, as opposed to on-premises appliance-based WAFs, are more likely to provide this feature while streamlining the setup for implementation.

Using FortiWeb Cloud as a File Scanning Platform

FortiWeb Cloud is designed to protect web applications against a wide range of threats. When properly configured, it can also scan uploaded files to detect malware, greyware, malicious scripts, and other harmful content, ensuring that a file is legitimate and safe to use.

To achieve this, it uses a multi-layered scanning approach that combines signature-based detection and behavioral analysis for comprehensive protection.

• Signature-based detection compares uploaded files against a database of known malware signatures. FortiWeb Cloud uses up-to-date virus definitions and threat intelligence to keep detection accurate and reliable.

• Behavioral analysis (via FortiSandbox) runs files in an isolated environment to observe their real-time behavior. This makes it possible to identify advanced threats such as zero-day malware or sophisticated attacks that static methods may miss.

Together, these mechanisms offer greater assurance that harmful content in files is detected before it can compromise systems or applications.

Submitting Files for Scanning

The idea behind this implementation is to provide a simple graphical interface or API endpoint that accepts files for evaluation through the WAF’s scanning features. The solution is expected to return a success status code only when the files are legitimate. It should act as a middleware layer, standardising received submissions into formats supported by FortiWeb Cloud and presenting error messages in a clearer, more digestible way, for example, explicitly flagging when a file exceeds the maximum size allowed for analysis.

File upload via multipart/form-data

The multipart/form-data format is the most common and suggested approach for file uploads, as it efficiently handles binary data. FortiWeb Cloud can process and scan files directly from this format, requiring no additional steps.

POST /upload HTTP/2
Host: domain.tbl
User-Agent: Mozilla/5.0 (compatible; MSIE 11.0; Windows; Windows NT 6.2; Win64; x64; en-US Trident/7.0)
Accept-Encoding: gzip, deflate, br, zstd
Content-Type: multipart/form-data; boundary=---------------------------41762806061171117218568726803
Content-Length: 656499
Connection: keep-alive

-----------------------------41762806061171117218568726803
Content-Disposition: form-data; name=”email”

johndoe@domain.tbl
-----------------------------41762806061171117218568726803
Content-Disposition: form-data; name=”file”; filename=”landscape.png”
Content-Type: image/png

[binary file data]

-----------------------------41762806061171117218568726803--

The JavaScript code below uses the axios package to send an HTTP request as the example shown above:

const sendFile = (formFile) => {
  const formData = new FormData();
  formData.append(”file”, formFile);

  return axios.post(”/upload”, formData, {
    headers: {
      “Content-Type”: “multipart/form-data”
    }
  });
};

FortiWeb Cloud can also scan files that are base64-encoded and embedded in JSON objects.

Whatever the Method, Validate File Content for Safety

File content validation is the third essential block to address when securing file upload features in web applications, alongside file name sanitization, file type validation, and resource limit enforcement.

Files such as PDFs, office documents, and media files can contain various forms of malicious content, including hidden scripts, obfuscated payloads, or parser exploits. In some cases, uploads are deliberately crafted for phishing, disguised as invoices or reports to trick users into disclosing sensitive data.

When it comes to media files, OWASP recommends techniques such as image rewriting to remove malicious code injected into images. For Microsoft documents, certain validation libraries can also be employed to help ensure the content is legitimate.

The specific approach you choose to implement file content validation is less important than ensuring the process is effective. Analysing a file’s structure, using certain validation libraries, or applying rewriting techniques can be more complex and time-consuming, but remain entirely valid.

At the end of the day, the goal lies in adopting a validation process that ensures file content is safe before it reaches your systems or users.

Reading Picks

Here are a few articles I found valuable in recent weeks:

• What to do before refactoring by

• To Cache or Not to Cache by

• Cognitive load is what matters by Artem Zakirullin

File type validation in upload features is usually based on three indicators: the Content-Type header, the Magic Number signature, and the File Extension. However, none of them provide complete trust from a security perspective.

At best, these checks serve as superficial filters to quickly discard obvious mismatches, but they cannot guarantee that the file is what it claims to be. Extensions can be renamed, headers can be spoofed, and magic numbers can be forged.

Let’s break down their practical role and show how they can be used wisely, meaning as quick filters that can simplify validation without giving them more trust than they deserve.

File Type Validation via the Content-Type Header

The Content-Type header is used to indicate the original MIME type (e.g., image/png, text/plain, application/pdf) of the resource prior to any content encoding applied before transmission.

MIME, short for Multipurpose Internet Mail Extensions, is a standard developed in the early 1990s to enable emails to include multimedia content and other binary files, and it is also employed on the web to define the nature of the data in the message body, the encoding applied, and how it should be processed or displayed:

HTTP/1.1 200 OK
Content-Type: multipart/form-data; boundary="ExampleBoundary"

--ExampleBoundary
Content-Disposition: form-data; name="text"

Here is the text you were looking for.

--ExampleBoundary
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg

[binary JPEG data]

--ExampleBoundary--

Validating file types using the MIME type from the Content-Type header is unreliable for security because the header is provided by the client and can be trivially spoofed—even though some libraries and packages rely on it to assert that an upload matches the expected type.

As example, the following implementation uses multer to handle file uploads, which identifies the file type via the received Content-Type HTTP header, and mistakenly uses it as the basis for a security check:

const ALLOWED_TYPES = ["image/jpeg", "image/png"];

const upload = multer({
  ...
});

app.post("/upload", upload.single("file"), (req, res) => {
  if (!req.file) {
    res.status(400).json({ message: "No file uploaded" });
    return;
  }

  const { mimetype } = req.file;

  if (!ALLOWED_TYPES.includes(mimetype)) {
    res.status(400).json({ message: "Unexpected file type" });
    return;
  }

  res.send("File uploaded successfully");
});

How to Manipulate the Content-Type Header

Malicious users can manipulate the Content-Type header in HTTP requests to bypass validation that relies on this header to determine the file type. The following curl command offers a straightforward way to demonstrate how to send a malicious PHP file while spoofing the Content-Type header to appear as a jpeg file:

curl -F "file=@malicious.php;type=image/jpeg" https://domain.tbl/upload

If the server relies solely on the Content-Type header for validation, this request will be accepted and the file treated as a JPEG despite containing PHP code.

File Type Validation via the Magic Number

The magic number is a unique sequence of bytes located at the beginning of a file’s content that is used to identify the file type, according to a list of file signatures. These bytes serve as a signature for the file, allowing the operating system or applications to determine its type, even without relying on the file extension:

• jpeg (jpg) files start with FF D8 FF DB (corresponding to ÿØÿÛ).

• png files start with 89 50 4E 47 0D 0A 1A 0A (corresponding to ‰PNG␍␊␚␊).

• pdf files start with 25 50 44 46 2D (corresponding to %PDF-).

• zip files start with 50 4B 03 04 (corresponding to PK␃␄).

The code snippet below uses the npm file-type package, which identifies the file type via the magic number, and then proceeds with a security check that can be easily circumvented through the manipulation of the file’s signature:

import { fileTypeFromBuffer } from "file-type";

const ALLOWED_TYPES = ["image/jpeg", "image/png"];

const upload = multer({
  ...
});

app.post("/upload", upload.single("file"), async (req, res) => {
  if (!req.file) {
    res.status(400).json({ message: "No file uploaded" });
    return;
  }

  const { buffer } = req.file;

  // Get the MIME type from buffer
  const fileType = await fileTypeFromBuffer(buffer);

  if (!ALLOWED_TYPES.includes(fileType.mime)) {
    res.status(400).json({ message: "Unexpected file type" });
    return;
  }

  res.send("File uploaded successfully");
});

Bypassing Magic Number Checks

Malicious users can easily prepend a valid magic number to malicious files, making them seem legitimate. For instance, adding the %PDF-2.0 signature at the start of a webshell file can trick the system into thinking it’s actually a PDF file. This can actually be the process:

1. Let’s start by showing the content of the original webshell.php file:

:~$ cat webshell.php 
<?php system($_GET[”cmd”]); ?>

2. Then, determine the file type by using the file system command, confirming its original format as PHP:

:~$ file webshell.php
webshell.php: PHP script text, ASCII text

3. Proceed to add the appropriate magic number for a PDF file (i.e., %PDF-2.0) at the beginning of the file:

:~$ echo “%PDF-2.0$(cat webshell.php)” > webshell.php

4. Display the content of the webshell.php file once more to verify the change:

:~$ cat webshell.php
%PDF-2.0<?php system($_GET[”cmd”]); ?>

5. Show the hex dump of the file to check the initial bytes, ensuring they correspond to 25 50 44 46 2D as stated in the list of file signatures:

:~$ xxd webshell.php 
00000000: 2550 4446 2d32 2e30 3c3f 7068 7020 7379  %PDF-2.0<?php sy
00000010: 7374 656d 2824 5f47 4554 5b22 636d 6422  stem($_GET[”cmd”
00000020: 5d29 3b20 3f3e 0a                        ]); ?>.

6. Determine the file type again using the file command, and notice how it has changed to PDF:

:~$ file webshell.php
webshell.php: PDF document, version 2.0

As you can see, the outcome is a malicious file that tools that rely on the magic number will report as a PDF.

File Type Validation via the File Extension

In security terms, a file extension is little more than noise. Its role is limited to guiding the operating system—particularly Windows—in choosing which application should open the file. Unix-like systems, however, often ignore extensions altogether and instead rely on the magic number to determine the format. Since extensions are not enforced by the OS as protection mechanisms and serve only as usability metadata, they cannot be regarded as a reliable security measure.

That said, legitimate files are still expected to carry the appropriate extension. This is why extension validation is performed: not as a true security control, but as a superficial filter to quickly reject obvious inconsistencies.

For instance, the following multer implementation validates extensions by checking for .jpg, .jpeg, or .png, but this simplistic approach is insecure and can be circumvented through a double extension evasion technique:

const express = require(”express”);
const multer = require(”multer”);

const upload = multer({
  ...
});

const app = express();

app.post(”/upload”, upload.single(”file”), (req, res) => {
  if (!req.file) {
    res.status(400).json({ message: “No file uploaded” });
    return;
  }

  const { originalname } = req.file;

  if (!originalname.match(/\.(jpg|jpeg|png)/)) {
    res.status(400).json({ message: “Unexpected file extension” });
    return;
  }

  res.send(”File uploaded successfully”);
});

How Attackers Bypass File Extension Checks

• Using uppercase letters (e.g., .pHp, .pHP5 or .ASP).

• Adding a valid extension before the execution extension (e.g., image.png.php or image.png.php5).

• Adding special characters at the end (e.g., file.php%20, file.php%0d%0a or file.php/).

• Tricking the server-side extension parser by using techniques such as inserting junk data (null bytes) between extensions (e.g., image.php%00.png or image.php\x00.png).

• Adding another layer of extensions (e.g., image.png.jpg.php or image.php%00.png%00.jpg).

• Putting the execution extension before the valid extension, which can be useful in case of server misconfigurations (e.g., image.php.png).

• Using NTFS Alternate Data Stream (ADS) in Windows inserting a colon character : after a forbidden extension and before a permitted one (e.g., image.asp:.jpg).

Performing Secure File Extension Validation

File extensions should only be validated after file names have been properly sanitized. Keeping this order prevents attackers from hiding tricks within filenames and ensures extension checks are consistently applied.

Use the following guidelines to keep uploads restricted to safe, authorised extensions:

• Decode from URL-encoded format file names prior to validation to prevent bypass techniques like null byte characters (e.g., image.php%00.png).

• In cases where the web application only accepts a single file type (e.g., .pdf), hardcode the allowed extension when storing the file. If multiple file types are permitted, define an allow-list that restricts file extensions to only those necessary for business needs (e.g., .jpg, .jpeg and .png).

• Reject files that have missing or multiple extensions, unless explicitly required, to reduce the risk of exploitation.

• Apply robust filtering when validating to avoid common pitfalls, such as regex patterns that can be bypassed.

The code snippet below secures the file upload feature by properly decoding the file name before validation, applying an allow-list of allowed extensions, and preventing files with multiple or missing extensions:

const ALLOWED_EXTENSIONS = [".jpg", ".jpeg", ".png"];

const isAllowedFileExtension = (filename) => {
  const decodedFilename = decodeURIComponent(filename);
  const lowerCaseFilename = decodedFilename.toLowerCase();
  const lastDotIndex = lowerCaseFilename.lastIndexOf(".");

  if (lastDotIndex === -1) return false; // No extension found
  if (lowerCaseFilename.split(".").length - 1 > 1) return false; // Multiple extension found

  const extension = lowerCaseFilename.slice(lastDotIndex);

  return ALLOWED_EXTENSIONS.includes(extension);
};

const upload = multer({
  ...
  fileFilter: (req, file, cb) => {
    if (isAllowedFileExtension(file.originalname)) {
      cb(null, true);
      return;
    }

    const error = new multer.MulterError("LIMIT_UNEXPECTED_FILE", file.fieldname);
    error.message = "Unexpected file extension";
    cb(error);
  }
});

File Extension Validation on the Client-Side

File extension can also be easily checked on the frontend using the HTML accept attribute, which helps prevent users from sending unexpected files, though it is not reliable for security purposes:

<input type="file" id="fileInput" accept=".jpg, .jpeg, .png" />

To wrap up, the most reliable way to determine a file’s type is not by checking the Content-Type header, the Magic Number signature, or the File Extension, but by evaluating its actual content with specialised security tools and platforms—and relying on them to decide whether the file should be accepted or rejected. We’ll take a closer look at this approach in the upcoming post.

Interesting Reads

Some interesting articles I read in the past days:

• Cognitive load is what matters by Artem Zakirullin

• Frequent reauth doesn’t make you more secure by Avery Pennarun

File name sanitization is a crucial process in applications handling file uploads to ensure user-provided names are both safe and compatible with the systems where they will be stored or processed. It involves validating and modifying the original names of uploaded files to prevent security threats or operational failures that could compromise system integrity.

How Attackers Exploit File Names

At first glance, a file name looks harmless. But to an attacker, it’s an opportunity. Because many applications don’t treat them as untrusted input, they can be abused in clever and dangerous ways.

Injection payloads

The risk can come not from the file itself but the way the name is processed. If an application fails to sanitize properly, malicious strings in file names can trigger existing vulnerabilities:

• sleep(20)-- -.jpg → can lead to SQL injection if the file name is concatenated unsafely into a SQL query without proper escaping or parameterization.

• <svg onload=alert("XSS")>.jpg → can lead to Cross-Site Scripting (XSS) when the file name is reflected into a web page (HTML, attribute, or JS context) without proper encoding, or when user-supplied SVG content is served/executed in the browser.

• ; sleep 20;.jpg → can lead to OS Command injection if the file name is passed by concatenation into a shell or system API.

Enumeration leaks

When uploaded files are renamed poorly, attackers can predict or brute-force file names and access other users’ content. For instance, if an application simply appends a counter to duplicates:

• First upload: profile.jpg → stored as profile.jpg.

• Second upload: profile.jpg → stored as profile_2.jpg.

• Third upload: profile.jpg → stored as profile_3.jpg.

An attacker could guess profile_2.jpg, profile_3.jpg, etc., and retrieve private files from other users.

Extension tricks and truncation

Some systems enforce file name length limits, and mishandling them can introduce vulnerabilities. On Linux, where file names are limited to 255 bytes, a crafted example could be:

aaaa...[very long string]...php.png

This may bypass a code-based filter yet still be interpreted as PHP if application logic trims or slices names improperly, for example, by truncating the trailing .png to prevent exceeding the length limit.

Path traversal

By sneaking in ../ sequences, attackers can climb outside the intended upload directory and place files where they don’t belong:

../../../../var/www/html/index.php

This could overwrite the main application file with malicious content.

As seen, file names may appear harmless, but neglecting to verify them becomes a security risk.

The code snippet below shows an insecure file upload using multer in an Express app where the user’s original file name is used without validation:

const multer = require("multer");

const storage = multer.diskStorage({
  filename: (req, file, cb) => {
    cb(null, file.originalname); // Using file name provided by the user
  }
});

This pattern exposes the application to path traversal, injection attacks, hidden or double-extension files, accidental overwrites and cross-platform naming collisions.

Best Secure File Name Practices

As a developer, whenever possible, you need to generate unique and random file names (e.g., UUIDs or GUIDs) instead of relying on user-provided names. This solves both operational errors caused by duplicate names and security vulnerabilities tied to user-controlled file names.

If business requirements make this approach unfeasible, then apply these safeguards:

• Enforce a maximum file name length.

• Restrict allowed characters (e.g., A-Z, a-z, 0-9, -, _, and .).

• Avoid hidden files and trailing periods or spaces (e.g., .htaccess).

• Block reserved names in Windows and Linux.

• Handle file names as case-insensitive.

Use Unique and Random File Names

Assigning random and unique names to uploaded files prevents file name collisions, mitigates path traversal attacks, hides original names that could reveal sensitive data, blocks injection attempts, and protects against file enumeration.

This approach is particularly useful in scenarios where the original file names provided by users do not need to be retained:

const uuid = require("uuid");

const storage = multer.diskStorage({
  filename: (req, file, cb) => {
    cb(null, `${uuid.v4()}.pdf`); 
  }
});

In this illustrative case, the code uses a UUID to generate unique names and enforces the .pdf extension assuming the application is restricted to PDF uploads.

When Business Needs Prevent Random Naming

Sometimes applications need to preserve user-provided names for usability, compliance, or business logic. In those cases, security should not be sacrificed—you still can apply strict safeguards to keep file handling safe.

Enforce a maximum file name length

Different operating systems impose different limits on file name length. Legacy systems like FAT only support the old 8.3 format, while file systems like NTFS allow up to ~255 characters per filename, and ext4 allows up to 255 bytes. Excessive filename length can result in truncation, storage errors, or extension loss that lets files be misread or executed differently. Defining a safe maximum length (for example, 100 characters) prevents both technical complications and potential abuse:

const MAX_FILENAME_LENGTH = 100;

const decodedFilename = decodeURIComponent(file.originalname);

if (decodedFilename.length > MAX_FILENAME_LENGTH) {
  throw new Error("File name too long");
}

Restrict allowed characters

Not every character is safe in a file name. Allowing symbols, control characters, or special operators can backfire—creating risks such as path traversal or injection attacks. A safer approach is to limit file names to a small set of characters, for example: letters (A–Z, a–z), numbers (0–9), dots (.), underscores (_), and hyphens (-). Keeping names simple and predictable helps avoid cross-platform issues and reduces the attack surface significantly:

// Keep only alphanumerics, dots, underscores, and hyphens
const restrictedFilename = decodedFilename.replace(/[^A-Za-z0-9._-]/g, "");

Avoid hidden files and trailing dots or spaces

File names that begin with a dot are hidden on UNIX-like systems (for example, .htaccess used by Apache). Attackers can exploit this to disguise malicious uploads or override server configuration. Similarly, names ending with spaces or periods are handled inconsistently across operating systems, sometimes causing access errors or unexpected behavior. Stripping leading dots (unless explicitly allowed) and removing trailing spaces or periods closes this gap and keeps uploaded files predictable and safe:

// Strip leading dots and trailing dots/spaces
const trimmedFilename = restrictedFilename.replace(/^[.]+|[.\s]+$/g, "");

Block reserved names

File systems enforce restrictions on certain names that cannot be used for files. In Windows, names such as CON, AUX, PRN, NUL, and COM1–COM9 are reserved, and characters like <, >, :, ", /, \, |, ?, and * are not allowed. In Linux and other UNIX-like systems, the null character (\x00) and the forward slash (/) are forbidden in names, while . and .. are reserved as directory references. Filtering these values during validation prevents uploaded files from conflicting with the operating system or breaking file system logic:

const sanitizeFilename = require("sanitize-filename");

// Remove system-reserved filenames
const sanitizedFilename = sanitizeFilename(trimmedFilename);

This example uses the npm package sanitize-filename, which automatically strips unsafe characters and reserved names, simplifying validation.

Treat file names as case-insensitive

On Linux, Report.pdf and report.pdf are two different files. However, on Windows and MacOS, they’re treated by default as the same file. This mismatch can cause confusion, accidental overwrites, or even unauthorized access. A reliable way to prevent this is to normalize every file name to lowercase (or uppercase) and treat them as case-insensitive. This ensures consistent behavior regardless of where your application runs:

// Normalize casing for consistency across platforms
const normalizedFilename = sanitizedFilename.toLowerCase();

It’s important to keep the order of the operations, otherwise a later step can undo the protections of an earlier one—for example, restricting characters after stripping leading dots could still leave an unsafe name. By applying checks in the right sequence—decode, check length, restrict characters, strip dots and spaces, block reserved names, normalize case—you ensure every safeguard actually holds.

Interesting Reads

Some interesting articles I read in the past days:

• How to Become a Confident Software Engineer by

• REST API Essentials: What Every Developer Needs to Know by

• Vulnerable vs. Exploitable: Why Understanding the Difference Matters to Your Security Posture

When applications don’t properly validate the files users submit, such as their name, extension, content, or resource usage, attackers can exploit this to upload malicious files. From there, the consequences can quickly escalate.

Why Insecure File Uploads Are So Risky

A poorly protected upload function can serve as a gateway to severe attacks:

• Remote Code Execution (RCE): Malicious scripts uploaded and executed on the server can give attackers full control.

• Cross-Site Scripting (XSS): Uploaded HTML, SVG, or other files containing scripts can be used to hijack user sessions, steal data, or redirect to malicious sites.

• SQL Injection: File names used directly in database queries without sanitization can drop tables or exfiltrate data.

• Command Injection: File names passed to system commands can execute arbitrary code.

• Parser Flaws: Vulnerabilities in file parsers (PDF, XML, media) can be abused for crashes or code execution.

• Path Traversal: Manipulated filenames (../) can traverse directories, exposing or altering sensitive files, enabling defacement and integrity loss.

• Data Leakage: Metadata or hidden content inside files can expose sensitive information.

• Malware Delivery: Files can carry different types of malware targeting servers or end users.

• Phishing: Disguised uploads (e.g., invoices, HR docs) can trick employees into revealing sensitive information.

• Denial of Service (DoS): Oversized or excessive uploads can overwhelm server resources, disrupt network performance, or limit storage capacity, causing service downtime.

Components Attackers Exploit in File Uploads

When it comes to insecure uploads, attackers don’t just rely on a single trick, but every part of a file can become an attack vector if left unchecked.

File Name

Manipulated names can include path traversal sequences (../) to escape directories, overwrite sensitive files, inject malicious SQL payloads to alter queries and exfiltrate data, or even trigger commands when passed to system utilities.

File Extension

Executable files (.exe, .elf) can run malware or perform unwanted actions, while source files (.php, .js, .py) may be interpreted by the server, leading to arbitrary code execution. Even compressed files (.zip, .tar) can smuggle multiple malicious payloads.

File Content

PDFs, office docs, and media files can hide embedded scripts, obfuscated payloads, or parser exploits. Some uploads are crafted for phishing—appearing as invoices or reports to lure victims into revealing data.

File Limits

Oversized or repeated uploads can consume CPU, RAM, bandwidth, or storage, leading to resource exhaustion and potential Denial of Service (DoS).

How to Secure File Uploads

Because there’s no single silver bullet, securing file uploads requires a defense-in-depth strategy—multiple layers of validation, sanitization, and controls. The goal is simple: no file should ever be processed or stored unless it has passed every security check.

Key Best Practices

• Start with general validation: Ensure that any existing general input validation process is performed prior to other validation steps.

• Sanitize file names: Generate random names (e.g., UUIDs) for storing or enforce strict allow-lists for characters and length.

• Control extensions: Only allow business-required extensions; block absent and redundant extensions.

• Check actual content: Verify file type against its data and scan with antivirus or sandbox tools.

• Set limits: Enforce maximum file size and prevent excessive or repeated uploads.

• Harden storage: Store files on a dedicated service or at least outside the webroot, enforce least-privilege permissions, and avoid execute rights.

• Require authentication: Restrict who can upload and who can access uploaded files.

• Use trusted frameworks: Leverage mature libraries for preprocessing instead of reinventing validation.

• Protect against CSRF: Ensure upload endpoints are safeguarded against Cross-Site Request Forgery (CSRF).

• Stay updated: Keep dependencies and parsing libraries patched and securely configured.

In the upcoming posts, I’ll break down each of these practices in detail, showing how attackers exploit weak points and how to implement the right defenses.

Reading Picks

Here are a few articles I found valuable in recent weeks:

• APIs Versioning by

• Why XSS Persists in This Frameworks Era? by Canalun

• The Simple Habit That Lowers Stress, Boosts Energy, and Improves Health by

Curiosity, learning, and hands-on testing are what brought us here today, to this online exchange between writer and reader. Knowledge has always fueled human progress, and it continues to shape the way we understand and build technology.

However, AI is now reshaping nearly everything we do, especially how we develop applications. Developers used to spend hours digging, testing, and figuring things out. Now we often just ask. That makes us faster and more productive, but when it comes to complex areas like security, things aren’t that simple. Security influences everything, from system performance and application usability to data integrity and user privacy.

The truth is, you can’t build secure systems without really understanding security. If you don’t know the threats, you can’t pick the right defenses. AI can give useful hints, but without the right context, you might not apply them correctly, and that’s when trouble happens.

These days, people assume applications need to be secure by default. Teams expect developers to deliver features quickly, meet business requirements, and avoid security gaps. All at once.

This is precisely why knowledge remains such a powerful advantage. AI is great, but genuine understanding gives you perspective. It helps you learn faster, solve harder problems, and work smarter.

For me, building secure systems is not just about adhering to best practices or integrating AI-driven advice. It is about being prepared for challenging scenarios, deeply understanding the technology, and enjoying the learning process itself.

That’s what motivates me to write this newsletter: to share what I’ve researched, tested, and learned in terms of security, hopefully in a way that makes life a little easier for all engineers.

I hope you find it useful.

Ferran