DEV Community: Rajath

If You're Building Microservices Without This, You're Doing It Wrong

Rajath — Fri, 06 Mar 2026 19:18:30 +0000

Imagine walking into a massive, bustling restaurant. What if, instead of speaking to a waiter, you had to walk into the kitchen yourself? You’d have to track down the grill chef for your steak, find the pastry chef for your dessert, and flag down the bartender for your drink.

It would be exhausting, chaotic, and horribly inefficient.

In the software world, client applications (like the mobile apps on your phone or the web browsers on your laptop) used to face this exact problem when trying to talk to modern cloud applications. That is, until the API Gateway came along to act as the ultimate waiter, concierge, and traffic cop all rolled into one.

If you’re wrapping your head around modern system architecture, understanding the API Gateway is a massive lightbulb moment. Let’s break down what it is, why it exists, and how it keeps the digital world from collapsing into chaos.

What Exactly is an API Gateway?

At its most basic level, an API Gateway is a piece of software that sits between a client and a collection of backend services.

Instead of an app trying to talk to a dozen different servers to load a single webpage, the app talks to only the API Gateway. The gateway takes that request, figures out which backend services are needed to fulfill it, gathers all the data, and hands a neat, completed package back to the user.
It acts as the single "front door" for your application. Whether a request is coming from an iPhone, an Android, or a web browser, they all knock on the same door.

Why Do We Need It? (The "Before and After")

To understand why API Gateways are suddenly everywhere, we have to look at how software design has changed.

The Old Way: Monoliths

Historically, applications were built as monoliths—everything (billing, user profiles, inventory, etc.) lived in one giant codebase on one server.

The New Way: Microservices

Today, we use microservices. We break applications down into dozens or even hundreds of tiny, independent services. This is great for developers because it makes updating and scaling much easier. But it’s a nightmare for the client side.

Without an API Gateway, a mobile app loading an e-commerce storefront would have to make separate network calls over the internet to the Inventory Service, the Pricing Service, the Reviews Service, and the Recommendation Service.

Here’s a comparison of how the communication flow changes.

Direct Client-to-Microservice Communication (No Gateway)

This approach is slow, consumes user battery, and makes the app fragile.

Communication with an API Gateway

By using an API Gateway, the complexity is hidden from the user. The mobile app makes one call to the gateway. The gateway does the heavy lifting of running around the "kitchen" to fetch the inventory, pricing, and reviews, over the ultra-fast internal network, saving the user's battery life and sanity.

The 4 Superpowers of an API Gateway

Routing traffic is just the beginning. Because the gateway is the only way in or out of your backend, it’s the perfect place to enforce rules. We can visualize these 'Superpowers' as layers of responsibility.

Let's break these down:

The Bouncer (Security & Authentication): Instead of forcing every single microservice to independently verify if a user is logged in, the gateway handles it. It checks the user's API keys, JWT tokens, or OAuth credentials right at the door. If you aren't on the list, you don't get in.
The Shield (Rate Limiting & Throttling): If a malicious bot network tries to flood your servers, or a viral post sends a million users your way at once, the API Gateway steps in. It limits how many requests a single user or IP address can make per second, preventing your backend servers from crashing.
The Translator (Protocol Translation): Sometimes, the front-end speaks a different language than the back-end. A web browser might request data using standard HTTP, but your internal microservices might communicate using faster, more complex protocols like gRPC or WebSockets. The gateway translates these requests on the fly.
The Speedster (Caching): If thousands of people are asking for the exact same data (like the homepage of a news site), the gateway can save a copy of the response. Instead of bothering the backend databases every single time, it just hands the user the cached copy, drastically speeding up load times.

Should You Always Use One?

While they sound amazing, API gateways aren't a silver bullet. They introduce a single point of failure and slightly increase latency for simple setups.

Here is a quick decision flow to see if you need one:

🚀 Keep Learning!

If you enjoyed this breakdown of API Gateways and want to dive deeper into software architecture, I've got you covered.

🌍 Read this anywhere!

Prefer reading on DEV Community? You can also find this article (and drop a unicorn reaction!) over on my dev.to profile:
🦄 Read on dev.to

Curious about how to actually set one of these up? Stay tuned for my next blog post where we'll dive into the implementation details!

How to Protect Your Web App from Malware via File Uploads

Rajath — Fri, 27 Feb 2026 08:46:06 +0000

If your web application has an <input type="file"> tag anywhere in its architecture, you have a massive target on your back.

File upload features are essential for modern applications—whether it’s uploading a profile picture, a CSV of user data, or a PDF report. However, if improperly handled, a simple file upload form is the easiest way for an attacker to achieve Remote Code Execution (RCE), deface your server, or distribute malware to your users.

In this post, we are going to look at the real-world vulnerabilities associated with file uploads and build a "defense in depth" strategy to secure them.

The Threat Landscape: What Can Go Wrong?

When you allow a user to upload a file, you are inherently allowing them to write data to your disk. If you blindly trust the file they provide, you open yourself up to:

Web Shells (RCE): An attacker uploads a .php or .jsp file containing a malicious script. If your server executes it, they own your machine.
Directory Traversal: An attacker intercepts the upload request and changes the filename to ../../../etc/passwd to overwrite critical system files.
Denial of Service (DoS): An attacker uploads a massive 10GB file, or a "zip bomb," instantly consuming all your server's memory and disk space.
Cross-Site Scripting (XSS): An attacker uploads a malicious .svg or .html file masquerading as an image. When another user views it, malicious JavaScript executes in their browser.

To stop these, we need a multi-layered approach.

Layer 1: Never Trust User Input (Validation)

The biggest mistake developers make is trusting the file extension or the Content-Type header sent by the client. Both are trivially easy to spoof using tools like Burp Suite or Postman.

Bad Practice:

Python

# DO NOT DO THIS
if filename.endswith('.jpg') and request.headers['Content-Type'] == 'image/jpeg':
    save_file()

Good Practice: Validate Magic Bytes Instead of trusting the extension, you must inspect the actual contents of the file. Every file type has a "Magic Number" or file signature—a short sequence of bytes at the very beginning of the file that identifies its true format.

Here is how you validate magic bytes in Python using the python-magic library:

Python

import magic
from werkzeug.utils import secure_filename

ALLOWED_MIME_TYPES = {'image/jpeg', 'image/png', 'application/pdf'}

def is_safe_file(file_stream):
    # Read the first 2048 bytes to determine the file signature
    file_header = file_stream.read(2048)
    file_stream.seek(0) # Reset the pointer back to the start!

    # Identify the true MIME type based on the file contents
    actual_mime_type = magic.from_buffer(file_header, mime=True)

    return actual_mime_type in ALLOWED_MIME_TYPES

Layer 2: Filename Sanitization

Never use the original filename provided by the user. Attackers use crafted filenames to execute Path Traversal attacks, attempting to save files outside of your designated upload directory.

The Solution: Completely discard the user's filename. Generate a unique, random string (like a UUID) for the file upon upload, and append the validated extension to it. If you need to keep the original filename for UI purposes, store it safely as a string in your SQL database, not on the filesystem.

Python

import uuid
import os

def generate_safe_filename(actual_extension):
    # Generates a name like: 550e8400-e29b-41d4-a716-446655440000.jpg
    random_name = str(uuid.uuid4())
    return f"{random_name}.{actual_extension}"

Layer 3: Secure Storage Architecture

If you take only one lesson from this article, let it be this: Never store uploaded files in your web root. If your web server (like Apache or Nginx) is configured to serve files from /var/www/html, and you save user uploads to /var/www/html/uploads, you are risking execution. If an attacker slips a script past your filters, they can simply navigate to yourdomain.com/uploads/shell.php to execute it.

The Modern Standard: Cloud Object Storage (S3)

The safest architectural pattern is to decouple file storage from your application server entirely.

Direct-to-S3 via Presigned URLs: Instead of routing a massive file through your Java or Python backend (which ties up server threads and costs money), your backend should generate a temporary, restricted "Presigned POST URL".
The client's browser uses this URL to upload the file directly to an AWS S3 bucket.
The S3 bucket is configured with policies that prevent execution, and you can trigger AWS Lambda functions to automatically scan the uploaded file with an antivirus (like ClamAV) before moving it to a "Clean" bucket.

How Big Tech Handles Uploads at Scale

When companies like Slack, Netflix, or Meta process millions of files an hour, passing large blobs of data through a standard web server is a recipe for crashing your infrastructure. They take the "Defense in Depth" strategy even further using a few core patterns:

1. The Quarantine Pattern (Asynchronous Scanning) Large applications never upload files directly to a production environment. Instead, they use a "Quarantine Bucket." When a user uploads a file directly to cloud storage, it triggers an event-driven serverless function (like AWS Lambda). This function asynchronously runs an antivirus scanner (like ClamAV) and checks the magic bytes. Only if the file gets a clean bill of health is it moved to the primary production bucket.

2. Resumable Uploads (The Tus Protocol) If a user is uploading a massive 4K video or a huge dataset and their connection drops at 99%, failing the upload is terrible UX. Companies like Vimeo and Cloudflare use the open-source Tus protocol or AWS Multipart Uploads. This breaks the file down into small chunks and uploads them individually, allowing the client to pause and resume uploads seamlessly.

3. Edge Processing (CDNs) Once a file is validated and stored securely, it needs to be served fast. Instead of storing five different sizes of the same profile picture, large platforms use Edge networks (like Cloudflare, AWS CloudFront, or Akamai). They store the high-resolution original securely, and then dynamically compress and resize the image "on the fly" at the edge node closest to the user requesting it.

Summary Checklist for Secure Uploads

Before you deploy your next file upload feature, ensure you check these boxes:

✅ Implement a strict Allow list for file types (no blacklisting).

✅ Validate file types using Magic Bytes, not extensions.

✅ Enforce Max File Size limits at the server configuration level to prevent DoS.

✅ Rename all files using UUIDs.

✅ Store files outside the web root or, ideally, in isolated Cloud Object Storage like S3.

✅ Serve files with the correct headers: X-Content-Type-Options: nosniff and Content-Disposition: attachment.

Handling file uploads securely takes a bit more architecture, but it is the difference between a robust enterprise application and a compromised server.

Have you encountered any tricky edge cases when handling file uploads in your own projects? Let me know in the comments below!