🧠 Two “AllowedHosts” Every Developer Should Know

Whether you’re in .NET, Node.js, Java, or Python — you need to care about what hosts your app trusts.
This is one of those small details that can quietly make or break your app’s security posture.

And it’s straight out of the OWASP Top 10:
→ A10:2021 – Server-Side Request Forgery (SSRF) and
→ A01:2021 – Broken Access Control.

Let’s check both sides of “allowed hosts”

1️⃣ The Built-in One: Protecting Inbound Traffic

In ASP.NET Core, you’ll often see this in appsettings.json:

{
  "AllowedHosts": "example.com"
}

That’s not for redirects, API calls, or URLs inside your app.
It’s for incoming HTTP requests — it tells your app which Host headers are allowed.
If someone tries to access your server as https://evilproxy.com, the request is dropped.

Think of it as your front door lock 🏠 —
It stops fake domains from pretending to be you.

💡 Other frameworks have similar controls:

Express.js → use helmet() or host-validation middleware

Django → ALLOWED_HOSTS in settings.py

Spring Boot → server.forward-headers-strategy with a proxy-aware filter

2️⃣ The Custom One: Protecting Outbound URLs (OWASP SSRF)

Now comes the untold part:
Even if your app’s front door is locked, what about the URLs inside it?

When users can submit or trigger URLs (for example, a redirect after login, a webhook, or an image fetch), attackers can trick your backend into calling something internal like http://localhost:8080/admin.

That’s Server-Side Request Forgery (SSRF) — and it’s on OWASP’s radar for a reason.
The fix? A custom whitelist middleware that validates every URL before use.

🧱 Code Example: .NET Middleware to Block Untrusted URLs

Here’s a simple example in C# — easy to adapt to any stack:

using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Options;
using System;
using System.Linq;
using System.Threading.Tasks;

public class UrlWhitelistMiddleware
{
    private readonly RequestDelegate _next;
    private readonly string[] _allowedHosts;

    public UrlWhitelistMiddleware(RequestDelegate next, IOptions settings)
    {
        _next = next;
        _allowedHosts = settings.Value.AllowedHosts;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var returnUrl = context.Request.Query["returnUrl"].ToString();

        if (!string.IsNullOrEmpty(returnUrl) && !IsAllowed(returnUrl))
        {
            context.Response.StatusCode = 400;
            await context.Response.WriteAsync("Blocked: Untrusted redirect target.");
            return;
        }

        await _next(context);
    }

    private bool IsAllowed(string url)
    {
        if (!Uri.TryCreate(url, UriKind.Absolute, out var uri))
            return false;

        if (uri.Scheme != Uri.UriSchemeHttps && uri.Scheme != Uri.UriSchemeHttp)
            return false;

        return _allowedHosts.Any(host =>
            uri.Host.Equals(host, StringComparison.OrdinalIgnoreCase) ||
            uri.Host.EndsWith("." + host, StringComparison.OrdinalIgnoreCase));
    }
}

public class SecuritySettings
{
    public string[] AllowedHosts { get; set; } = Array.Empty();
}

Add your whitelist in appsettings.json:

{
  "Security": {
    "AllowedHosts": [ "example.com", "trustedpartner.org" ]
  }
}

And register it in your app:

app.UseMiddleware();

✅ TL;DR — What Devs Should Remember

Purpose Type Example OWASP Relevance

• Inbound host validation Built-in AllowedHosts Prevents Host Header Injection A05:2021

• Security Misconfiguration
  Outbound / redirect URL validation Custom middleware whitelist Prevents SSRF, open redirects A10:2021 – SSRF

🔐 Final Word

Whether you write in .NET, Node, or Go, make your app paranoid about URLs like you are when clicking on a link received in an email.
A trusted host list is one of the simplest, cheapest, and most effective shields against SSRF and open redirect attacks.

🧩 Lock the door. Guard the window.
OWASP and Reality has been warning us for years — time to listen, especially devs and software architects.