DEV Community: David Jesse Odhiambo

The Mechanics of CLI Mistakes: Pipes, Redirection, and Stream Adjacency

David Jesse Odhiambo — Fri, 09 Oct 2026 05:19:50 +0000

It is 1:30 AM. PagerDuty just woke you up. An alert is firing across a production cluster, your terminal history is a blur of half-remembered flags, and every second the incident remains unmitigated feels like an eternity.

You need to locate an errant service dump or isolate a single anomalous IP hammering your endpoints. You type a command you have executed a million times. You hit Enter.

Instead of a clean output, your terminal buffer explodes with a thousand lines of unreadable Permission denied errors, blowing past your scrollback limit. Or worse: the prompt returns quietly in milliseconds with an empty output—or dirty data—giving you zero indication of what failed.

You sit there in the dark, squinting at the screen, frustrated, asking yourself: “Why didn't that work? I swear, that command was right.”

It was not right. It was muscle memory betraying you.

Small syntactic oversights in the shell rarely trigger helpful stack traces. Instead, they betray how Unix handles standard streams and file descriptors under the hood.

This guide dissects two insidious command-line mistakes that routinely trip up engineers during high-pressure audits:

The Pipeline Fallacy: Why chaining | 2>/dev/null fails to suppress standard error.
Stream Adjacency: Why uniq silently passes duplicate records unless fed a sorted stream.

We examine the exact Unix mechanics behind both failures, provide battle-tested fixes, and outline the production contexts where these errors cost real engineering hours.

Companion Resource: Production debugging patterns, terminal syntax breakdowns, and incident response playbooks are documented in the open-source devops-playbook repository.

Case Study 1: The Pipeline Fallacy (`| 2>/dev/null`)

The Incident Scenario

You are investigating an alert on an unfamiliar host. An unprivileged application process crashed, leaving behind an orphaned credential or state file. You know three attributes of the target file:

Target owner: bill

Target group: ted

Exact file size: 254 bytes

You execute a recursive search starting from the root directory (/):

find / -user bill -group ted -size 254c

Because you are running the command as an unprivileged user, find attempts to traverse restricted directories such as /root, /etc/ssl/private, and /proc.

The result is immediate noise. Hundreds of error lines flood the terminal:

find: ‘/root’: Permission denied
find: ‘/etc/polkit-1/localauthority’: Permission denied
find: ‘/var/spool/cron/crontabs’: Permission denied
...

The single matching path you need is buried somewhere in that wall of text.

The Failed Fix: The Broken Pipe

To eliminate the noise, muscle memory kicks in: pipe the errors away. So you append | 2>/dev/null:

find / -user bill -group ted -size 254c | 2>/dev/null

The result? The exact same flood of Permission denied errors coats your screen.

Depending on your shell, you might even receive an additional parsing complaint:

bash: 2>/dev/null: command not found

Why It Fails: Unix Stream Mechanics

To understand this failure, consider how the shell manages Unix standard streams and file descriptors (FDs):

Standard Input (stdin / FD 0): The stream the process reads for input.
Standard Output (stdout / FD 1): The stream where the process sends normal runtime output.
Standard Error (stderr / FD 2): The stream where the process writes error diagnostics and status warnings.

+---------------------------------------+
|  find / ...                           |
|    FD 1 (stdout) ------> [ Pipe | ] ------> Expects executable command
|    FD 2 (stderr) -------------------------> Attached to Terminal (Unfiltered)
+---------------------------------------+

When you construct the command find ... | 2>/dev/null, two distinct breakdowns occur:

Pipes redirect stdout, not stderr: The pipe operator (|) connects the stdout (FD 1) of the command on the left to the stdin (FD 0) of the command on the right. It leaves stderr (FD 2) untouched and attached to your interactive terminal.
The right side of a pipe requires a command: A pipe expects an executable binary, shell builtin, or function on its receiving end. The syntax 2>/dev/null is an I/O redirection directive, not an executable. The shell cannot execute a redirection operator as a program.

Because find continues writing its permission failures directly to FD 2, the error stream completely bypasses the pipe.

The Correct Pattern

Apply the redirection operator directly to the invocation of find, without a pipe operator:

find / -user bill -group ted -size 254c 2>/dev/null

Syntax Breakdown

find /: Recursively search the file hierarchy starting at the root directory.
-user bill: Filter entries owned by user bandit7.
-group ted: Filter entries owned by group bandit6.
-size 254c: Match files with an exact size of 33 bytes (the suffix c specifies bytes).
2>/dev/null: Redirect file descriptor 2 (stderr) away from the terminal and into the /dev/null pseudo-device (a bit bucket that discards all data written to it).

Clean Terminal Output

/var/lib/dpkg/info/timetravel.log

By discarding FD 2 at the source, stdout passes cleanly to the screen, surfacing the target artifact immediately.

Production Impact

On production systems, running broad discovery searches as an unprivileged service account or during a restricted audit session is standard practice.

Failing to redirect file descriptors correctly introduces operational risk:

Log Contamination: Appending noisy commands to CI/CD diagnostic steps or incident runbooks pollutes central aggregation engines (Datadog, CloudWatch, Loki) with gigabytes of useless permission logs.
Masked Success Criteria: When piping command outputs into automated scrapers or monitoring scripts, leaked stderr lines can cause downstream JSON or regex parsers to throw parse exceptions.

Case Study 2: The Adjacency Trap (`uniq -u`)

The Incident Scenario

A distributed API endpoint is reporting anomalous spike latencies. You pull an unsorted raw telemetry extract, data.txt, containing hundreds of request tokens and service signatures.

Your task is triage isolation: find the single, non-recurring anomaly—the exact unique string that appeared once when the downstream service choked.

You know the standard GNU core utility designed for this exact purpose: uniq. Because you need only lines that occur exactly once, you supply the -u (unique) flag:

uniq -u data.txt

The Silent Failure: False Positives

Instead of isolating that single anomalous record, the terminal prints dozens of lines. When you inspect the output, you spot duplicate entries staring right back at you.

Here is a simplified trace of what data.txt contains:

token_alpha
token_beta
token_alpha
token_gamma
token_beta

When you execute uniq -u data.txt, the terminal returns:

token_alpha
token_beta
token_alpha
token_gamma
token_beta

Wait, shouldn't uniq -u return unique lines? The command did not fail with a non-zero exit code. It did not produce an error message. It simply failed to perform the logical deduplication you expected.

Why It Fails: Stream Adjacency Mechanics

The behavior of uniq is not broken; it is adhering strictly to its Unix design constraints.

uniq was engineered as a low-overhead, memory-bounded stream processor. It does not ingest the entire dataset into an in-memory hash set or balanced binary tree. Doing so on a multi-gigabyte log file would exhaust system RAM and invoke the Linux Out-Of-Memory (OOM) killer.

Instead, uniq performs a state machine comparison using an internal single-line buffer:

Stream Input:
[token_alpha] -> Buffer holds: token_alpha  (First line: kept)
[token_beta]  -> Compare with: token_alpha  (Different: previous emitted, new buffered)
[token_alpha] -> Compare with: token_beta   (Different: previous emitted, new buffered)

Because token_alpha was separated by token_beta, uniq evaluates the second occurrence of token_alpha as a fresh entity. It has no memory of what it read two lines ago.

To uniq, duplicate entries are only duplicates if they are adjacent.

The Correct Pattern

Precondition the input stream by piping the raw file through sort before executing uniq:

sort data.txt | uniq -u

Syntax Breakdown

sort data.txt: Reads the entire dataset, orders records lexicographically, and writes the sorted stream to standard output (stdout). This groups identical tokens into contiguous blocks.
|: Standard Unix pipe, connecting the stdout of sort to the standard input (stdin) of uniq.
uniq -u: Filters the contiguous stream, discarding any token cluster with a frequency count greater than 1, emitting only lines that appear exactly once.

Clean Terminal Output

token_gamma

The sorting pass clusters identical lines together (token_alpha, token_alpha, token_beta, token_beta, token_gamma), enabling uniq's two-line sliding window to correctly identify and drop the duplicates.

Production Impact

Relying on uniq without an upstream sort during live incident mitigation introduces severe risks:

Corrupted Root Cause Analysis (RCA): If you pipe an unsorted stream into uniq -c to calculate event frequencies or error distributions, your metric counts will be fragmented across multiple separate lines rather than aggregated into true totals.
CPU and Memory Trade-offs: While uniq is O(N) with tiny memory overhead, sort requires O(N \log N) compute time and buffers data in memory (spilling to /tmp for large sets). In high-volume log investigations, understanding this trade-off tells you when to run sort | uniq versus using an in-memory aggregation tool like awk '!seen[$0]++'.

Mastering the Subtleties of the Shell

The difference between a frantic incident investigation and a fast, surgical fix rarely comes down to esoteric kernel tuning. It comes down to standard I/O mechanics, file descriptors, and stream buffers.

When you understand that:

Pipes link standard output to standard input, leaving file descriptor 2 attached to your terminal, and
uniq is a lightweight streaming filter that relies entirely on contiguous adjacency,

you stop wrestling with unexpected terminal noise and start constructing predictable, deterministic pipelines. Muscle memory is useful, but foundational mechanics keep systems running when everything else is breaking.

Contribute to the Playbook

We are building an open-source collection of real-world Linux command breakdowns, edge cases, and incident mitigation patterns over at devops-playbook.

Whether it is a subtle flag combination in xxd, a trap inside tar extraction paths, or an edge case in awk, every utility has failure modes that cost engineers hours.

Star the repo to keep these quick-reference patterns in your toolkit.

Open a PR or issue with the CLI syntax friction points you have run into during your own late-night debugging sessions.

Let's build a zero-fluff manual that saves engineers from unnecessary production headaches.

Demystifying SSH Key Management and Security Inside Windows Subsystem for Linux (WSL)

David Jesse Odhiambo — Wed, 16 Sep 2026 19:44:29 +0000

Transitioning from GUI-assisted tools to the command line gives you complete control over your systems workflows. However, running Secure Shell (SSH) inside Windows Subsystem for Linux (WSL) often exposes friction across environment boundaries. Sharing keys directly from the host Windows file system triggers silent permission mismatches and fatal Permissions 0777 are too open errors because the underlying NTFS drive mounts ignore standard POSIX access controls. This guide shows you how to isolate cryptographic keys natively within the WSL file system, enforce strict file permissions, and automate credential handling with ssh-agent.

The Architecture: Host vs. WSL Boundary

WSL mounts your Windows host drives under /mnt/c/ through a translation file system (DrvFs/9P). While this lets you access Windows files from Linux, it creates a critical architectural divide between two separate file systems:

Host Mount (/mnt/c/Users/<user>/.ssh): Stored on Windows NTFS. By default, DrvFs translates NTFS Access Control Lists (ACLs) by assigning permissive 0777 permissions to every file, ignoring standard POSIX ownership.
Native Linux Directory (~/.ssh or /home/<user>/.ssh): Stored inside WSL's virtual ext4 disk (ext4.vhdx), which fully supports native Linux file modes and ownership.

Because the OpenSSH client requires private keys to be accessible exclusively by the owner, pointing SSH to keys in /mnt/c/ causes immediate authentication failures. To maintain security and avoid permission rejections, store and manage your SSH keys strictly within the native Linux file system at ~/.ssh.

Generating and Securing Keys Inside WSL

Generate an asymmetric key pair inside your WSL terminal using the modern Ed25519 algorithm:

ssh-keygen -t ed25519 -C "wsl-dev"

Prefer Ed25519 over legacy RSA. It produces compact 256-bit keys that offer stronger cryptographic resistance against side-channel attacks, faster signature generation, and smaller payload footprints than typical 2048-bit or 4096-bit RSA keys.

Once generated, enforce strict POSIX permissions. The OpenSSH client audits file modes on execution and aborts connections if keys are readable by other system users:

Target	Path	Required Permission	Command
Directory	`~/.ssh`	700 (drwx------)	`chmod 700 ~/.ssh`
Private Key	`~/.ssh/id_ed25519`	600 (-rw-------)	`chmod 600 ~/.ssh/id_ed25519`
Public Key	`~/.ssh/id_ed25519.pub`	`644 (-rw-r--r--)`	`chmod 644 ~/.ssh/id_ed25519.pub`

Verifying these octal modes ensures compliance with OpenSSH's security checks and protects your private keys from exposure across shared local environments.

Streamlining Sessions with ssh-agent

Protecting your private key with a passphrase is essential, but re-entering it for every SSH session, Git push, or remote server transition interrupts terminal workflows. You can eliminate this friction using ssh-agent, a background program that caches your unencrypted keys in memory.

Initialize the agent and load your key into the active session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Once loaded, OpenSSH authenticates automatically without prompting for your passphrase until the session closes.

To automate this across all new WSL shell sessions without launching duplicate background processes every time you open a tab, append this lightweight check to your ~/.bashrc:

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)" > /dev/null
    ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

Common Pitfalls: The Drvfs Mount Trap

Attempting to fix permissions on Windows-mounted keys by running chmod 600 /mnt/c/Users/<user>/.ssh/id_rsa fails silently. The command exits with status 0, but ls -l reveals the permissions remain 0777.

This happens because the DrvFs driver ignores POSIX file metadata updates unless explicitly enabled in /etc/wsl.conf:

[automount]
options = "metadata"

While adding metadata allows chmod to persist on NTFS files, relying on host mounts introduces unnecessary cross-filesystem overhead and risks ACL collisions. The production standard remains absolute: generate and keep your SSH keys strictly within the native WSL ext4 filesystem.

The Bottom Line

Isolating your keys inside the native WSL ext4 filesystem prevents NTFS permission rejections. Enforce strict 700 and 600 modes to satisfy OpenSSH security standards, and automate ssh-agent in your ~/.bashrc to maintain secure, frictionless terminal workflows.

Full-Stack Interview Prep #2: XSS (Cross-Site Scripting) Explained Simply (with Go & Node.js Examples)

David Jesse Odhiambo — Tue, 02 Sep 2025 16:32:55 +0000

You’re in a technical interview. The interviewer leans back and asks:
“How would you protect a web app from Cross-Site Scripting (XSS)?”

For a moment, your mind races. You know XSS is common, but how do you explain it clearly under pressure?

Let’s break it down with a simple example: imagine a user comment box on a blog. Instead of leaving normal feedback, an attacker types:

<script>alert('hacked')</script>

If the site displays that comment without filtering or escaping it, the attacker’s code will run in the browser of anyone who visits the page. What should have been a friendly comment section just became a tool for stealing sessions, hijacking accounts, or tricking users into clicking malicious links.

That’s Cross-Site Scripting in a nutshell: when untrusted input makes its way into a webpage, and browsers treat it as executable code instead of harmless text.

Why does this matter? Because XSS is still listed in the OWASP Top 10 — which means that even after two decades, it continues to affect real-world applications. From social media platforms to e-commerce sites, XSS has caused data leaks, account takeovers, and reputational damage for companies that overlooked secure coding practices.

What is XSS? (Explained Simply)

Think of XSS like this: imagine a suggestion box at a store. Customers drop in notes with feedback. Most are normal, like “Great service!” But one prankster slips in a fake note that says “Read this out loud and embarrass yourself.” The staff reads it, not realizing it’s a trick.

That’s what Cross-Site Scripting does — only instead of words, the “fake note” is malicious code, and the victim is every user’s browser.

A Plain-English Example

Imagine a blog with a comment section. A normal user writes:

Great article, thanks for sharing!

But an attacker posts: <script>alert('hacked')</script>

If the site displays that input without escaping it, the browser doesn’t see it as a comment. It sees it as code to run. The result? Every visitor who loads that page gets an unexpected popup — or worse, the attacker could steal cookies, hijack accounts, or inject fake login forms.

The Flow of an XSS Attack

Here’s the basic lifecycle of how XSS sneaks in:

Attacker Input → Saved in Database → Rendered in HTML → Browser Executes Script

At first glance, it looks like harmless text. But once it reaches the browser, the line between “data” and “code” becomes indistinguishable.

Types of XSS (Quick Overview)

There are three common flavors of XSS:

Stored XSS → malicious input is saved in the database (e.g., a comment or profile field).
Reflected XSS → the malicious input comes from a URL or form, and the server reflects it back in the response.
DOM-based XSS → the attack happens entirely in the browser when client-side JavaScript inserts untrusted input into the page.

Don’t worry if these terms feel new — we’ll use simple code examples in the next section to make them concrete.

XSS in Practice (Bad Examples)

So far we’ve talked about XSS in theory — now let’s see what it looks like in real code.

Imagine we’re building a simple comment feature for a website. A user types something, we save it, and then we display it back on the page. Straightforward, right? But if we’re not careful, this is exactly where XSS slips in.

❌ Go Example (Vulnerable Template Rendering)

In Go, if we use the text/template package or print raw input without escaping, we risk injecting user input directly into the HTML:

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    comment := r.URL.Query().Get("comment")
    // ❌ Vulnerable: directly writing unescaped input to the response
    fmt.Fprintf(w, "<h1>User Comment:</h1> %s", comment)
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Now if an attacker visits:

http://localhost:8080/?comment=<script>alert('XSS')</script>

Instead of displaying harmless text, the browser executes the <script> tag, and everyone sees an alert box pop up.

❌ Node.js Example (Express App Rendering Input Directly)

The same issue happens in Node.js if we inject user input straight into the HTML without escaping:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  const comment = req.query.comment;
  // ❌ Vulnerable: directly embedding user input in HTML
  res.send(`<h1>User Comment:</h1> ${comment}`);
});

app.listen(3000, () => console.log('Server running on http://localhost:3000'));

If someone visits:

http://localhost:3000/?comment=<script>alert('XSS')</script>

Boom — the browser pops up the alert box again. What should have been “just text” was treated as code.

The Key Takeaway: This is a simple example of how XSS works in practice. As we saw earlier, it can appear as stored, reflected, or DOM-based attacks — the form changes, but the root cause is always the same: untrusted input being injected into a page without proper handling.

How to Prevent XSS (Best Practices)

Now that we’ve seen how XSS sneaks into your program, let’s focus on defense. The good news is: protecting against XSS doesn’t require magic — just discipline and the right tools.

Think of prevention as layers of defense: some fixes are essential, others add extra safety nets. Together, they make your app resilient.

1. Output Encoding / Escaping

The golden rule: never trust user input when rendering it back to a page. Instead, escape it so the browser treats it as text, not code.

🚨 Vulnerable vs. ✅ Safe (Quick Comparison)

Sometimes, the fix is just one small change — but it makes all the difference.

In Golang

// ❌ Vulnerable: text/template does NOT escape input
import "text/template"

// ✅ Safe: html/template auto-escapes <script> and other dangerous tags
import "html/template"

In Node.js → if you use template engines like EJS, Pug, or Handlebars, they escape output by default.

// ❌ Vulnerable: raw string interpolation, user input becomes HTML
res.send(`<h1>User Comment:</h1> ${comment}`);

// ✅ Safe: use a template engine (EJS, Pug, Handlebars)
// Escaping happens by default
res.render('index', { comment });

Interview Tip: Be ready to explain that secure defaults (like Go’s html/template or Express template engines) are your best defense. Interviewers love to hear that you understand both the why and the how.

2. Use Security Libraries

Sometimes you do want to allow limited HTML (like bold or italic tags in a blog comment). In that case, use a sanitization library that strips dangerous tags and attributes.

Node.js → DOMPurify is a battle-tested option (often used with server-side rendering).

Go → packages like bluemonday provide configurable sanitizers.

3. Content Security Policy (CSP)

CSP is like a seatbelt: it won’t prevent an accident, but it can reduce the damage. By setting a CSP header, you can tell browsers to only run scripts from trusted sources.

Example header:

Content-Security-Policy: script-src 'self'

This means: only run JavaScript that comes from my own site, not from injected code.

4. Input Validation (Secondary Layer)

Validation alone won’t stop XSS (attackers can always craft clever payloads), but it can reduce noise. For example:

Reject inputs that are clearly invalid for the field (like a birthdate containing <script>).

Limit length of input to reduce payload size.

Think of this as cleaning the water before it reaches your filters.

5. Principle of Least Privilege

Finally, even if something slips through, you can reduce the impact by limiting what the attacker can do.

Cookies → mark them HttpOnly and Secure, so even if a script runs, it can’t steal them easily.

Database / API access → don’t give your web app more permissions than it needs.

Key Takeaway:
If you remember only one thing:
Always escape untrusted output.

Everything else — sanitization, CSP, validation, least privilege — are extra shields. But escaping is your first and strongest line of defense.

Why Interviewers Ask About XSS

At this point, you might be wondering: why does XSS keep showing up in interviews? It’s not because interviewers enjoy watching developers sweat — it’s because this single vulnerability reveals a lot about how you think as an engineer.

Here’s what they’re really looking for:

1. Do you know client-side vulnerabilities, not just backend ones?

Many developers focus only on the server. But XSS is a reminder that security isn’t just about the database — the browser is part of the attack surface too.

2. Can you explain attack → defense clearly?

It’s one thing to say “XSS is bad.” It’s another to walk through:

how it works (untrusted input becomes code), and
how to fix it (escape output, sanitize input, use CSP). That step-by-step clarity is exactly what interviewers want to hear.

3. How do you handle pressure?

Sometimes the question isn’t asked in a calm, textbook way. Instead, you’ll hear things like:

“What’s the difference between stored and reflected XSS?”
“How would you prevent XSS in your favorite language?”
“Can you give me a real-world consequence of XSS?”

These versions test whether you can stay calm, think out loud, and structure your answer under pressure.

4. Do you understand the real-world impact?

Interviewers want to know if you see beyond code snippets. For example, XSS can:

Steal a user’s session cookies.
Hijack an account.
Inject fake login forms to harvest passwords.
Damage a company’s reputation when users lose trust.

A Simple Answer Framework

Here’s a 3-step structure you can use to answer almost any XSS interview question:

1. Define it simply

> “XSS happens when untrusted input is inserted into a webpage and executed as code in the browser.”

2. Give a quick example

> “For instance, if a site displays alert('hacked') from a comment box without escaping, that code will run for every visitor.”

3. Show how to prevent it

> “The fix is to always escape output (Go’s html/template, Node’s template engines), sanitize inputs, and enforce a Content Security Policy as backup.”

The key takeaway: XSS questions aren’t trivia. They’re a way for interviewers to test your security fundamentals, your ability to reason through problems, and your communication skills under pressure.

Pop Quiz: Test Your Understanding

Before we wrap up, let’s do a quick self-check. These aren’t trick questions — just simple ways to reinforce what you’ve learned. Try answering them in the comments to share your take and help others learn too.

1. Scenario Check

Imagine a blog comment box that doesn’t escape <script> tags. What happens if an attacker submits this as a comment?

<script>alert('hacked')</script>

2. True or False

Input validation alone is enough to completely stop XSS attacks.

3. Fix the Code (Go)

Here’s a vulnerable Go snippet:

fmt.Fprintf(w, "<p>%s</p>", comment)

Rewrite it using a safe approach so that <script> tags are not executed in the browser.

4. Fix the Code (Node.js)

Here’s a similar vulnerable snippet in Node.js (Express):

res.send(`<p>${comment}</p>`);

Rewrite it using a templating engine or escaping function to prevent XSS.

💡 Tip: Don’t worry about being “perfect.” The goal is to practice identifying vulnerable code and thinking of safer alternatives.

Conclusion / Call to Action

Cross-Site Scripting (XSS) is dangerous because it hijacks user trust — but it’s also preventable with a few simple practices. If you remember one rule, let it be this: never trust unescaped user input in your HTML output. Add layers like sanitization, CSP, and cookie protections, and you’ll be ahead of most real-world vulnerabilities.

Key Takeaways

XSS happens when untrusted input is executed as code in the browser.

Output escaping (Go html/template, Node templating engines) is your first line of defense.

Sanitization libraries (like DOMPurify) help when HTML input is unavoidable.

Content Security Policy (CSP) and secure cookie flags (HttpOnly, Secure) provide safety nets.

Your Next Steps

Audit your code for any direct string interpolation into HTML.
Use safe defaults: html/template in Go, EJS/Pug/Handlebars in Node.
Add or tighten a CSP header for your app.
Set cookies with HttpOnly and Secure to limit exposure.

Over to You

Have you ever discovered an XSS issue in your own project — maybe even by accident?

What fixes or defensive tricks have you found most useful? Drop your answers and quiz responses in the comments — let’s learn from each other.

Up Next in the Series

This was Full-Stack Interview Prep #2: XSS Explained Simply (with Go & Node.js Examples), a follow up to #1: SQL Injection Explained Simply.
Stay tuned for #3: CSRF (Cross-Site Request Forgery) Explained Simply with Go & Node.js Examples.

Full-Stack Interview Prep #1: SQL Injection Explained Simply (with Go & Node.js Examples)

David Jesse Odhiambo — Wed, 27 Aug 2025 15:06:54 +0000

You’re in a technical interview. The interviewer looks up from their notes and asks: “How would you protect a login form from SQL injection?” In that moment, your answer isn’t just about passing the interview — it’s about whether you understand one of the web’s most common security threats.

SQL Injection is when an attacker sneaks malicious input into a database query. Imagine a login form where you enter a username and password. Normally, the database should only check if those values exist. But if the code isn’t secure, an attacker could type something like admin' OR '1'='1. The database, confused, runs it as a valid command — and suddenly the attacker is logged in without ever knowing the real password.

More technically, SQL Injection happens when untrusted user input is placed directly inside an SQL query string. This breaks the separation between code and data, allowing attackers to alter the query’s logic — for example, turning a simple credential check into a query that returns every user in the database.

There’s a reason this topic keeps coming up in interviews: it’s not just theory. SQL Injection is still in the OWASP Top 10 after more than two decades, and a single overlooked query has cost companies millions in data breaches and lost trust.

💡 This article is the first in my Full-Stack Interview Prep series, where I break down common interview questions into simple explanations, real-world scenarios, and practical code examples in Go and Node.js. Each part of the series focuses on one core concept — from security topics like SQL Injection, XSS, and CSRF, to backend fundamentals like caching and authentication, and even frontend/system design essentials. My goal is to make these topics easier for developers preparing for interviews, while also showing recruiters how I approach teaching, collaboration, and writing clean, secure code.

What is SQL Injection? (Explained Simply)

Now that we’ve set the stage, let’s break down what SQL Injection really is — step by step, and in plain language.

Think of your SQL query as a conversation with the database. Normally, you ask a simple question like:
“Does a user named John exist with this password?”

But with SQL Injection, an attacker interrupts that conversation and sneaks in their own instructions. Instead of just typing John, they might type:

John' OR '1'='1

That small addition changes the meaning of the query. The database is tricked into thinking the condition is always true — which means the attacker could log in without knowing any real password.

Here’s a simplified SQL example to show what happens behind the scenes:

-- Normal query
SELECT * FROM users WHERE username = 'John' AND password = 'secret';

-- Injected query
SELECT * FROM users WHERE username = 'John' OR '1'='1' AND password = 'secret';

In the injected version, '1'='1' is always true. That makes the whole condition true, and the database happily returns a row — even if the password is wrong.

This is the essence of SQL Injection: when user input isn’t handled safely, it can alter the logic of a database query in dangerous ways.

SQL Injection in Practice (Bad Examples)

Let’s see how SQL Injection sneaks in through everyday code. These examples might look harmless, but they show what happens when user input is inserted directly into a query string.

Vulnerable Example in Go

// ❌ Vulnerable code
query := "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"
rows, _ := db.Query(query)

At first glance, this looks like a straightforward way to check if a user exists. But notice how we’re building the query by concatenating strings. That means whatever the user types in username or password gets injected directly into the SQL command.

Now imagine the attacker types this as the username:

admin' OR '1'='1

The query becomes:

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

Since '1'='1' is always true, the database happily returns a row — and the attacker is logged in without knowing a real password.

Vulnerable Example in Node.js

// ❌ Vulnerable code
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
db.query(query, (err, result) => {
  if (err) throw err;
  console.log(result);
});

The same issue appears here. By embedding username and password directly in the query string, we’re giving attackers a chance to alter the logic.

If the attacker enters the same payload (admin' OR '1'='1), the query becomes:

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

Again, the condition always evaluates to true, so the attacker bypasses authentication.

How to Prevent SQL Injection (Best Practices)

The good news is that SQL Injection is preventable. With a few best practices, you can protect your application — and your users — from this attack. Let’s walk through the most important defenses.

✅ Prepared Statements / Parameterized Queries

SQL Injection prevention starts with using prepared statements, sometimes called parameterized queries. Instead of directly inserting user input into a string, you pass the input as parameters. This keeps data separate from the query logic.

In Go (using database/sql):

// ✅ Safe code using parameters
query := "SELECT * FROM users WHERE username=$1 AND password=$2"
row := db.QueryRow(query, username, password)

Here, $1 and $2 act as placeholders. The database ensures that username and password are treated as values, not code.

In Node.js (using mysql2):

// ✅ Safe code using parameters
const query = "SELECT * FROM users WHERE username = ? AND password = ?";
db.query(query, [username, password], (err, result) => {
  if (err) throw err;
  console.log(result);
});

The ? placeholders ensure the same protection. No matter what an attacker types, it will always be treated as data, never as part of the SQL command.

✅ ORMs & Query Builders

Another way to reduce risk is by using an ORM (Object-Relational Mapper) or query builder. Tools like GORM (Go) or Prisma (Node.js) abstract away SQL and usually handle parameterization for you by default.

Example:

// Prisma in Node.js
const user = await prisma.user.findUnique({
  where: { username: username },
});

ORMs aren’t foolproof, but they help developers write cleaner queries with safer defaults.

✅ Input Validation & Escaping

While prepared statements are your primary shield, it’s also good practice to validate input. For example:

Ensure usernames only contain expected characters (letters, numbers).
Validate that email fields actually look like emails.

This isn’t enough on its own — but combined with parameterization, it makes your app much harder to exploit.

✅ Principle of Least Privilege

Even with secure queries, you should avoid giving your database user more permissions than it needs. For example:

Your application’s database account should not have rights to drop tables or manage users.
Restrict it to just what the app needs: SELECT, INSERT, UPDATE, DELETE.

This way, even if something goes wrong, the damage is limited.

Why Interviewers Ask This Question

So why do interviewers love asking about SQL Injection? It’s not just to check if you’ve memorized a definition. They use this question to see how you think, how you explain, and how you handle pressure.

Here are the main things they’re looking for:

🔹 1. Core Knowledge

Do you understand what SQL Injection is and why it matters? Interviewers want to confirm that you’re aware of common web vulnerabilities and can recognize insecure code when you see it.

🔹 2. Communication Skills

Can you explain the attack and its prevention clearly? Being able to walk through attack → defense in a way others can follow shows that you’re not only a good developer, but also someone who can mentor teammates and document your work.

🔹 3. Handling Pressure

Most interviewers won’t stop at a single question. They’ll push a little further to see if you can stay calm and keep your answers structured. For example, they might ask:

“What’s SQL Injection?”
“Can you give me an example in your favorite language?”
“How would you prevent it in Go/Node?”
“What happens if a company ignores this vulnerability?”

These follow-ups aren’t designed to trick you — they’re a chance to show that you understand the fundamentals and can adapt your answers.

Pop Quiz!

Before we wrap up, here’s a quick quiz to test your understanding. Don’t worry — this isn’t an exam. The goal is to practice, reinforce the concepts, and maybe even teach others by sharing your answers in the comments.

📝 Questions

1. Concept Check
What does the condition OR '1'='1 do when it appears in an SQL query?

2. True or False
Input validation alone is enough to completely prevent SQL Injection.

3.0. Fix the Vulnerable Code (Go)
Here’s a vulnerable Go query:

query := "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"
rows, _ := db.Query(query)

How would you rewrite this using a prepared statement to make it safe?

3.1. Fix the Vulnerable Code (Node.js)
Here’s a vulnerable Node.js query:

const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
db.query(query, (err, result) => { ... });

Rewrite it using parameterized queries to prevent injection.

💬 Try answering in the comments. Even if you’re not fully confident, writing out your thought process is one of the best ways to learn — and your answer might help another developer too.

Conclusion

SQL Injection is one of the simplest attacks to exploit, but also one of the simplest to prevent — as long as we use secure coding practices like prepared statements, validation, and proper permissions.

I’ll admit — early in my career, I wrote queries just like the vulnerable ones we saw earlier. It’s easy to do without realizing the risk. The important part is learning how to spot these mistakes and fix them before they reach production.

💬 Have you ever discovered SQL Injection risks in your own code? Share your experience in the comments — your story might help another developer catch the same mistake. And don’t forget to drop your answers to the quiz above; I’ll be checking in to give feedback.

👉 Next up in this series: XSS (Cross-Site Scripting) explained simply with Go & Node.js examples.

At the end of the day, secure coding isn’t just about passing interviews — it’s about protecting real people who trust us with their data.

Real-Time Messaging with Go and JavaScript

David Jesse Odhiambo — Mon, 02 Jun 2025 12:21:01 +0000

WebSockets allow your frontend and backend to talk instantly, without the old HTTP request/response delay. In this tutorial, we'll show you how to build a real-time chat application using Go on the backend and JavaScript on the frontend.

🚀 This is Part 3 of the WebSocket series. If you're just joining:

Start with Part 1: HTTP vs WebSockets: What Every Beginner Needs Know

Then check out Part 2: How to Build a Simple WebSocket Server in Go

Let’s put all of it to work now.

Project Overview

We’re building a very basic chat room where users can:

Send messages using a frontend form
Receive messages instantly from other users via WebSocket

Tech stack:

Go (Golang) + Gorilla WebSocket backend
HTML + JavaScript frontend

Backend Setup (Recap)

Here’s the Go server we used in Part 2:

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    // Allow all connections
    CheckOrigin: func(r *http.Request) bool { return true },
}

func handleWebSocket(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }
    defer conn.Close()

    for {
        messageType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Println("Read error:", err)
            break
        }

        log.Printf("Received: %s\n", msg)

        // Echo message back to client
        if err := conn.WriteMessage(messageType, msg); err != nil {
            log.Println("Write error:", err)
            break
        }
    }
}

func main() {
    http.HandleFunc("/ws", handleWebSocket)

    fmt.Println("Server started at http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

This server listens for incoming WebSocket connections at /ws, upgrades the HTTP connection, and echoes back any message it receives.

Frontend Code (HTML + JavaScript)

Here’s a minimal frontend you can save as index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Go WebSocket Chat</title>
  <style>
    body { font-family: sans-serif; padding: 2rem; }
    #messages { border: 1px solid #ccc; height: 300px; overflow-y: scroll; margin-bottom: 1rem; padding: 1rem; }
  </style>
</head>
<body>
  <h2>Chat</h2>
  <div id="messages"></div>
  <input type="text" id="msgInput" placeholder="Type a message...">
  <button onclick="sendMessage()">Send</button>

  <script>
    const ws = new WebSocket("ws://localhost:8080/ws");
    const messagesDiv = document.getElementById("messages");

    ws.onmessage = (event) => {
      const msg = document.createElement("div");
      msg.textContent = event.data;
      messagesDiv.appendChild(msg);
    };

    function sendMessage() {
      const input = document.getElementById("msgInput");
      ws.send(input.value);
      input.value = "";
    }
  </script>
</body>
</html>

How It Works

The browser opens a WebSocket connection to ws://localhost:8080/ws
When you type and click Send, JavaScript sends the message to the Go backend.
The Go server receives it and immediately echoes it back.
JavaScript listens for incoming messages and displays them.

It's a direct two-way pipeline — no reloading, no polling!

Debugging Tips

Browser Console Errors: Open DevTools (F12) to see if WebSocket failed to connect.
CORS Issues? Make sure your WebSocket server is on the same origin or add CORS headers.
Connection refused? Ensure your server is running on the right port.

Possibilities Beyond Chat

Now that you’ve got WebSockets working, here’s what else you can build:

✅ Real-time notifications
✅ Multiplayer games
✅ Live dashboards
✅ Collaborative editors (like Google Docs)

And with more tools:

🔐 Add authentication with JWT
🔁 Handle reconnects with backoff
⚙️ Scale using Redis pub/sub or message queues

Where We End

This wraps up our 3-part WebSocket series:

HTTP vs WebSockets: Why it matters
Building a WebSocket server in Go
Connecting that server to a live frontend

From here, you're ready to explore more advanced designs:

Broadcasting to many clients
Creating chat rooms
Scaling with channels and goroutines

Let me know in the comments what you're building with Go and WebSockets 👇

How to Build a Simple WebSocket Server in Go (Step-by-Step Guide)

David Jesse Odhiambo — Wed, 28 May 2025 13:40:02 +0000

In the previous article HTTP vs WebSockets: What Every Beginner Needs to Know we learned about WebSockets and how they power real-time features like chat apps and live dashboards. But how do you actually build one with Go?

In this beginner-friendly guide, we’ll walk through how to:

✅ Set up a WebSocket server in Go
✅ Handle real-time messages
✅ Connect to it from a browser using JavaScript

This is Part 2 of the series. If you’re new to WebSockets, read Part 1: HTTP vs WebSockets—What Every Beginner Should Know first.

🔌 What is Gorilla WebSocket?

Gorilla WebSocket is a popular Go package that makes working with WebSockets easier.

✅ Actively maintained
✅ Full control over message handling
✅ Works well with net/http

Setting up a WebSocket server in Go with Gorilla WebSocket

📦 Step 1: Install Gorilla WebSocket

While in your Go project's directory, open your terminal and run:

go get -u github.com/gorilla/websoc

🛠️ Step 2: Build the WebSocket Server

Let’s write a basic WebSocket server in Go.

Create a file named main.go:

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    // Allow all connections
    CheckOrigin: func(r *http.Request) bool { return true },
}

func handleWebSocket(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }
    defer conn.Close()

    for {
        messageType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Println("Read error:", err)
            break
        }

        log.Printf("Received: %s\n", msg)

        // Echo message back to client
        if err := conn.WriteMessage(messageType, msg); err != nil {
            log.Println("Write error:", err)
            break
        }
    }
}

func main() {
    http.HandleFunc("/ws", handleWebSocket)

    fmt.Println("Server started at http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

🌐 Step 3: Simple Frontend (HTML + JavaScript)

Create a file named index.html in the same folder:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>WebSocket Test</title>
</head>
<body>
  <h2>WebSocket Echo Client</h2>
  <input id="msgInput" type="text" placeholder="Type a message..." />
  <button onclick="sendMessage()">Send</button>
  <ul id="messages"></ul>

  <script>
    const ws = new WebSocket("ws://localhost:8080/ws");

    ws.onmessage = (event) => {
      const li = document.createElement("li");
      li.textContent = "Received: " + event.data;
      document.getElementById("messages").appendChild(li);
    };

    function sendMessage() {
      const input = document.getElementById("msgInput");
      ws.send(input.value);
      input.value = "";
    }
  </script>
</body>
</html>

▶️ Step 4: Run Your Server

Run the Go server:

go run main.go

Open index.html in your browser (just double-click it).
Type a message and click Send — you should see your message echoed back in the browser!

🧪 How It Works

Your browser connects to /ws using WebSocket protocol.
Messages are sent to the server.
The server reads them and echoes them back.
All communication happens over a persistent connection.

🚀 Next Steps?

You’ve just built a real-time WebSocket server with Go! Now imagine what else you can do:

Build a chat app 🗨️
Add notifications 🔔
Stream sensor data 📈

In the next article, Real-Time Messaging with Go and JavaScript, we’ll take this further with broadcasting messages to multiple clients (like a real chat room).

✅ Follow me for more beginner-friendly Go tutorials!
Drop a comment if you have questions, or if you’ve built something cool with WebSockets!

HTTP vs WebSockets: What Every Beginner Needs to Know

David Jesse Odhiambo — Tue, 27 May 2025 00:01:58 +0000

If you’re learning how the web works—especially as a Go developer—you’ve probably been using REST APIs and exchanging data via JSON. But as soon as you dip your toes into real-time features like live chat, stock tickers, or multiplayer games, you’ll hear about something called WebSockets.

So, what are WebSockets? Can they replace HTTP and JSON? And when should you use one over the other?

Let’s break it down in the simplest way possible.

HTTP: The Old Reliable

HTTP (Hypertext Transfer Protocol) is the most common way for browsers and servers to communicate.

The client (like your browser) sends a request.
The server sends a response.
The connection closes after each interaction.

This is perfect for actions like:

Loading a webpage
Submitting a form
Fetching JSON data from an API

But what if you need real-time updates? Like getting a new message the moment someone sends it?

That’s where HTTP falls short.

Enter WebSockets: Persistent, Real-Time Connections

WebSockets allow a browser and server to open a persistent connection.

The connection stays open.
Both sides can send messages anytime.
No need to repeatedly ask the server, "Is there anything new?"

This is called full-duplex communication: both client and server can talk to each other continuously.

Perfect for:

Live chats
Notifications
Live dashboards
Multiplayer games

WebSocket vs HTTP (with JSON)

Feature	HTTP (JSON)	WebSockets
Connection Model	Request-response	Persistent, open connection
Data Format	JSON	JSON / binary / text
Server-Initiated Msgs	No	Yes
Overhead	High (headers per request)	Low (single handshake)
Best For	CRUD, APIs	Real-time updates

So yes, WebSockets can replace JSON over HTTP in some cases—but they solve a different problem.

JSON is a data format.
WebSocket is a communication protocol.
You can still use JSON over WebSockets.

Real-World Example: Chat App

Using HTTP + JSON:

You keep sending requests every few seconds: “Any new messages?”
Server responds: “Nope. Still nothing.” (Wasted bandwidth)

Using WebSocket:

You connect once.
The server pushes a message to you as soon as someone sends it.
Efficient and instant.

Should You Always Use WebSockets?

Not really. Here's a quick guide:

✅ Use WebSockets when:

You need real-time updates
The server must push data to the client
You’re building chat apps, live games, or notifications

✅ Use HTTP (with JSON) when:

You're building standard CRUD APIs
Data doesn’t change often
SEO or caching is important

Conclusion

WebSockets don’t replace HTTP entirely—but they give you new possibilities. For Go developers (and frontend devs too), learning WebSockets opens the door to building real-time, modern web applications.

In the next article, we’ll build a simple WebSocket server in Go, and connect it to a browser using JavaScript. You’ll see just how easy (and powerful) it can be.

Ready to go real-time? Let’s dive in!

Stay tuned for Part 2: "How to Build a Simple WebSocket Server in Go (Step-by-Step Guide)"

DEV Community: David Jesse Odhiambo

The Mechanics of CLI Mistakes: Pipes, Redirection, and Stream Adjacency

Case Study 1: The Pipeline Fallacy (| 2>/dev/null)

The Incident Scenario

The Failed Fix: The Broken Pipe

Why It Fails: Unix Stream Mechanics

The Correct Pattern

Syntax Breakdown

Clean Terminal Output

Production Impact

Case Study 2: The Adjacency Trap (uniq -u)

The Incident Scenario

The Silent Failure: False Positives

Why It Fails: Stream Adjacency Mechanics

The Correct Pattern

Syntax Breakdown

Clean Terminal Output

Production Impact

Mastering the Subtleties of the Shell

Contribute to the Playbook

Demystifying SSH Key Management and Security Inside Windows Subsystem for Linux (WSL)

The Architecture: Host vs. WSL Boundary

Generating and Securing Keys Inside WSL

Streamlining Sessions with ssh-agent

Common Pitfalls: The Drvfs Mount Trap

The Bottom Line

Full-Stack Interview Prep #2: XSS (Cross-Site Scripting) Explained Simply (with Go & Node.js Examples)

What is XSS? (Explained Simply)

A Plain-English Example

The Flow of an XSS Attack

Types of XSS (Quick Overview)

XSS in Practice (Bad Examples)

❌ Go Example (Vulnerable Template Rendering)

❌ Node.js Example (Express App Rendering Input Directly)

How to Prevent XSS (Best Practices)

1. Output Encoding / Escaping

🚨 Vulnerable vs. ✅ Safe (Quick Comparison)

2. Use Security Libraries

3. Content Security Policy (CSP)

4. Input Validation (Secondary Layer)

5. Principle of Least Privilege

Why Interviewers Ask About XSS

1. Do you know client-side vulnerabilities, not just backend ones?

2. Can you explain attack → defense clearly?

3. How do you handle pressure?

4. Do you understand the real-world impact?

A Simple Answer Framework

1. Define it simply

2. Give a quick example

3. Show how to prevent it

Pop Quiz: Test Your Understanding

1. Scenario Check

2. True or False

3. Fix the Code (Go)

4. Fix the Code (Node.js)

Conclusion / Call to Action

Full-Stack Interview Prep #1: SQL Injection Explained Simply (with Go & Node.js Examples)

What is SQL Injection? (Explained Simply)

SQL Injection in Practice (Bad Examples)

Vulnerable Example in Go

Vulnerable Example in Node.js

How to Prevent SQL Injection (Best Practices)

✅ Prepared Statements / Parameterized Queries

✅ ORMs & Query Builders

✅ Input Validation & Escaping

✅ Principle of Least Privilege

Why Interviewers Ask This Question

🔹 1. Core Knowledge

🔹 2. Communication Skills

🔹 3. Handling Pressure

Pop Quiz!

📝 Questions

Conclusion

Real-Time Messaging with Go and JavaScript

Project Overview

Backend Setup (Recap)

Frontend Code (HTML + JavaScript)

How It Works

Debugging Tips

Possibilities Beyond Chat

Case Study 1: The Pipeline Fallacy (`| 2>/dev/null`)

Case Study 2: The Adjacency Trap (`uniq -u`)