Access Control
HTTP Server
Security
Web Server Configuration
Network Security

Enable access control on simple HTTP server

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

A simple HTTP server is easy to start, but it usually has no access control by default. If the server is exposing anything beyond public static content, you need at least some combination of authentication, authorization, transport security, and request filtering.

Decide What Kind of Access Control You Actually Need

Access control is not one feature. It usually includes:

  • authentication, proving who the client is,
  • authorization, deciding what that client may access,
  • transport protection, preventing credential theft in transit,
  • optional source restrictions such as IP allowlists.

For a minimal internal server, basic authentication plus HTTPS may be enough. For internet-facing systems, you usually need stronger session or token-based design.

Basic Authentication Example in Node.js

For a simple server, HTTP Basic authentication is often the smallest workable gate. It is not modern identity architecture, but it is easy to understand and can be acceptable for internal tools when paired with HTTPS.

javascript
1const http = require("http");
2
3const USERNAME = "admin";
4const PASSWORD = "secret";
5
6const server = http.createServer((req, res) => {
7  const auth = req.headers["authorization"];
8
9  if (!auth || !auth.startsWith("Basic ")) {
10    res.writeHead(401, { "WWW-Authenticate": "Basic realm=Protected" });
11    return res.end("Authentication required");
12  }
13
14  const encoded = auth.split(" ")[1];
15  const decoded = Buffer.from(encoded, "base64").toString("utf8");
16  const [user, pass] = decoded.split(":");
17
18  if (user !== USERNAME || pass !== PASSWORD) {
19    res.writeHead(403);
20    return res.end("Forbidden");
21  }
22
23  res.writeHead(200, { "Content-Type": "text/plain" });
24  res.end("Protected content
25");
26});
27
28server.listen(8080);

This is enough to demonstrate the control flow, but without HTTPS it exposes credentials to interception.

Add Simple IP Filtering When Appropriate

Sometimes the server is only meant for a trusted subnet or office network. In that case, an allowlist can complement authentication.

javascript
1const allowed = new Set(["127.0.0.1", "::1"]);
2
3if (!allowed.has(req.socket.remoteAddress)) {
4  res.writeHead(403);
5  return res.end("IP not allowed");
6}

IP filtering alone is weak on the open internet, but inside controlled networks it can reduce accidental exposure.

HTTPS Is Part of Access Control in Practice

Even simple authentication becomes unsafe if the connection is plain HTTP. If the credentials or tokens travel unencrypted, the access control is not really protecting much.

That is why production setups usually terminate TLS at a reverse proxy such as Nginx, Caddy, or an ingress controller, even if the application server itself stays simple.

Keep Authorization Separate from Authentication

If users have different permissions, do not stop at proving identity. Decide which routes or operations each identity may use. Even a simple internal server often needs read-only versus admin behavior.

The easiest structure is:

  1. authenticate the caller,
  2. attach an identity or role to the request,
  3. check authorization before serving the resource.

That separation keeps the server logic cleaner than hard-coding username checks in every route.

Common Pitfalls

  • Adding Basic authentication without HTTPS and exposing credentials in transit.
  • Treating IP allowlisting as a complete substitute for user authentication.
  • Mixing identity checks and per-route permission checks until the code becomes inconsistent.
  • Reusing hard-coded credentials in production instead of storing secrets properly.
  • Assuming a "simple" HTTP server does not need auditing or rate limiting if it serves sensitive data.

Summary

  • Access control usually means authentication plus authorization, not only a password prompt.
  • Basic authentication can protect a simple server if it is paired with HTTPS.
  • IP allowlists are useful as an extra layer, especially in internal environments.
  • Authorization should be kept separate from identity verification.
  • Even small HTTP servers need deliberate security choices once they expose non-public resources.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.