Distributed Applications Security

Explain Introduction.

Explain What Are Distributed Applications?.

Explain Expanded Attack Surface.

Explain Trust Between Services.

Modern software rarely runs on a single machine.

Today's applications are sprawling ecosystems: dozens or hundreds of cooperating services hosted across multiple data centers and cloud regions, communicating over networks,…

This distributed architecture enables scalability, resilience, and rapid development — but it also creates a dramatically enlarged and more complex attack surface than any…

Modern software rarely runs on a single machine.

Today's applications are sprawling ecosystems: dozens or hundreds of cooperating services hosted across multiple data centers and cloud regions, communicating over networks,…

This distributed architecture enables scalability, resilience, and rapid development — but it also creates a dramatically enlarged and more complex attack surface than any…

Understanding the security implications of distributed systems is essential for any security professional.

A distributed application is one in which components execute on multiple independent computing nodes that communicate via a network, coordinating to perform work on behalf of…

Distributed architectures have evolved significantly over the past three decades: Client-Server Architecture : The foundational distributed model.

A client (web browser, mobile app, desktop application) sends requests to a server, which processes them and returns responses.

Security in this model centers on authenticating clients, securing the communication channel (TLS), and protecting the server from malicious input.

A monolithic application presents one attack surface; a distributed application of equivalent functionality presents dozens.

Each service endpoint is a potential entry point.

Each internal service-to-service communication channel is a potential interception point.

Each third-party dependency is a potential supply chain risk.

In a distributed system, services must make trust decisions about requests from other services.

If Service A calls Service B on behalf of a user, Service B must determine: Is this request really from Service A?

Is Service A authorized to make this request?

Is the claimed user identity legitimate?

Traffic between services traverses networks — whether a shared data center network, a cloud virtual network, or the public internet.

Internal network traffic is often implicitly trusted ("if it's on our network, it must be ours"), a dangerous assumption that the Zero Trust security model explicitly rejects.

Even in private cloud networks, lateral movement by an attacker after an initial compromise is a major risk.

Distributed systems must manage state across multiple services, often using eventual consistency models.

Security state — such as session revocation or permission changes — must propagate reliably and promptly.

Lag in propagation can create windows of vulnerability where a revoked session or permission still grants access.

APIs are the primary interface of modern distributed applications, and they have become a top-tier attack target.

API Security connects to risk, controls, and evidence.

API Security connects to risk, controls, and evidence.

API Keys : Simple secret strings issued to API consumers to identify and authenticate them.

API keys are convenient but have limitations: they are long-lived (a compromised key remains valid until revoked), they do not inherently carry information about the calling user,…

API keys work well for server-to-server communication where the key can be stored securely.

OAuth Tokens : Bearer tokens issued by an authorization server, carrying scoped access rights.

All API inputs must be validated for type, format, length, and range before being processed or stored.

Failure to validate inputs is the root cause of injection vulnerabilities (SQL injection, command injection, XML injection, SSRF).

APIs should reject unexpected fields (use allowlists, not denylists), validate that numeric IDs are within expected ranges, and sanitize string inputs to remove or encode…

Key Definition — BOLA (Broken Object Level Authorization) : The most common critical API vulnerability.

Rate limiting controls how many requests a client can make in a given time window, preventing both abuse and denial-of-service attacks.

Rate limits should be applied per API key, per user, per IP, and at the service level.

When a rate limit is exceeded, APIs should return HTTP 429 (Too Many Requests) with a Retry-After header.

More sophisticated implementations use sliding window algorithms and adaptive limits that detect attack patterns (e.g., high error rates).

When Service A calls Service B, B must authenticate A.

Several mechanisms achieve this: Mutual TLS (mTLS) : Standard TLS requires only the server to present a certificate.

In mTLS, both client and server present certificates, and both validate the other's certificate.

This provides cryptographic proof of identity for both parties.

A service mesh is an infrastructure layer that handles service-to-service communication transparently, without requiring application code changes.

Popular implementations include Istio, Linkerd, and Consul Connect.

A service mesh typically provides: - Automatic mTLS : All service-to-service traffic is encrypted and mutually authenticated by default.

- Traffic policies : Fine-grained control over which services can communicate with which other services (authorization policies).

Microservices require secrets (database passwords, API keys, TLS certificates, encryption keys) to function.

Hardcoding secrets in code or configuration files is a critical mistake — it leads to credential exposure in source code repositories and container images.

Dedicated secrets management systems — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets (with encryption at rest) — provide secure storage, access…

Containers package application code and its dependencies into an isolated runtime environment.

Docker is the dominant container runtime.

Key Docker security concerns: Image Vulnerabilities : Container images are built from base images (e.g., ubuntu:22.04, node:18-alpine) that may contain known vulnerabilities.

Images must be scanned before deployment using tools like Trivy, Snyk, or Clair.

Kubernetes (K8s) is the dominant container orchestration platform, managing the deployment, scaling, and networking of containerized workloads.

Kubernetes introduces its own security complexity: - RBAC : Kubernetes has its own RBAC system controlling which users and service accounts can perform which operations on which…

Overly permissive RBAC is a common misconfiguration.

- Network Policies : By default, all pods in a Kubernetes cluster can communicate with all other pods.

Asynchronous message queues decouple services, enabling resilient, event-driven architectures.

Popular message brokers include Apache Kafka, RabbitMQ, and AWS SQS.

Security concerns include: Authentication and Authorization : Message brokers must require authentication from producers and consumers.

Kafka uses SASL (Simple Authentication and Security Layer) mechanisms (SCRAM, OAuth) for authentication and ACLs for authorization — controlling which clients can produce to or…

Remote Procedure Calls (RPC) allow services to invoke functions on remote services as if they were local calls.

gRPC, developed by Google, uses HTTP/2 as its transport and Protocol Buffers as its serialization format.

gRPC security features: - TLS by default : gRPC strongly encourages TLS for all communication; plaintext ("insecure") channels should only be used in development.

- mTLS : gRPC supports mutual TLS for bidirectional authentication.

DDoS attacks overwhelm a target service with traffic or requests, rendering it unavailable to legitimate users.

Modern DDoS attacks are categorized by the layer they target:

Distributed Denial of Service (DDoS) connects to risk, controls, and evidence.

Volumetric Attacks : Overwhelm the target's network bandwidth with massive volumes of traffic.

Common techniques include UDP flood, ICMP flood, and DNS amplification.

In amplification attacks, the attacker sends a small spoofed request (pretending to be the victim) to many open DNS or NTP servers; those servers send large responses to the…

Protocol Attacks : Exploit weaknesses in network protocol implementations to exhaust server or infrastructure resources.

CDN and Anycast Networks : Content Delivery Networks (CDNs) like Cloudflare, Akamai, and Fastly distribute traffic across a global network, absorbing volumetric attacks and…

Anycast routing means attack traffic is dispersed across many PoPs (Points of Presence) rather than concentrated at one target.

DDoS Scrubbing Services : Dedicated services that divert traffic through scrubbing centers, where attack traffic is filtered before clean traffic is forwarded to the origin.

Services like AWS Shield Advanced and Radware activate on-demand during attacks.

Introduction

What Are Distributed Applications?

Expanded Attack Surface

Trust Between Services

Where Introduction applies.

Where What Are Distributed Applications? applies.

How the difference changes the security decision.

Identify the asset or process at risk.

Choose a preventive, detective, or corrective control.

Explain what evidence would prove the control is working.

Define one core concept in plain language.

Compare two controls or threats from the week.

Apply one idea to a campus or business system.

Evaluate why a solution might fail in practice.

Collect evidence, not just screenshots.

Explain what the artifact proves.

Connect the proof back to risk and control selection.

Distributed Applications Security

Security is a decision process, not just a tool list.

Use the reading to justify practical choices.