DEV Community: Aditya Sharma

What Is a Man-in-the-Middle Attack? How Does TLS Stop It?

Aditya Sharma — Mon, 07 Sep 2026 07:32:47 +0000

When your browser connects to a website, data travels through networks you don't control. Routers, ISPs, cables, wireless access points. Any of these could, in principle, be operated by someone who can see or modify your traffic.

The obvious response is encryption. Encrypt the data before sending it, and an observer sees only ciphertext. But encryption alone doesn't solve the harder problem.

Before Alice can encrypt anything for Bob, she needs Bob's public key. And if someone is sitting between Alice and Bob, they can intercept that key exchange.

Alice → "Give me your public key"
              ↓
        Attacker intercepts
              ↓
        Sends attacker's key instead
              ↓
Alice encrypts to the attacker's key,
believing she's communicating with Bob

Alice now has an "encrypted" connection. But she's encrypting to the wrong person. The attacker decrypts her messages, reads or modifies them, re-encrypts to Bob's actual key, and forwards them. Both sides think they have a private connection. Neither does.

This is the core problem. Encryption protects communication only if you know whose key you're encrypting to. The interesting question isn't whether traffic can be encrypted. It's how Alice can verify that the key she received actually belongs to Bob.

A Public Key Doesn't Come with Identity

Public-key cryptography gives us a useful primitive: a key pair where one key can sign and the other can verify. As covered in the digital signatures article, a signature over some data proves that the signer possessed the corresponding private key at signing time.

But a public key by itself says nothing about who created it. Anyone can generate a key pair. The fact that you have a key labeled "belongs to example.com" doesn't make it true. What's needed is a trustworthy mechanism for binding a public key to an identity.

This is what a digital certificate does.

What a Certificate Is

A TLS certificate is a signed document. It contains a domain name, the server's public key, validity information, and the issuer. Critically, it includes a digital signature from a Certificate Authority that vouches for the binding between that domain and that public key.

Domain identity
       +
Server public key
       ↓
Certificate
       ↓
Signed by Certificate Authority

The CA's signature is what allows a client to verify that a trusted authority has attested to the binding between that domain identity and public key. Because the client can verify the CA's signature using the CA's public key, which it already has, a valid signature over the certificate means a trusted authority stands behind the claim that this public key belongs to this domain. Operating systems and browsers ship with a trust store: a set of root CA certificates that are considered trustworthy by default. If a certificate chains up to one of those roots, and the signature is valid, the client can trust that the domain-to-key binding has been attested by a trusted authority.

If an attacker creates a certificate for a target domain without the corresponding private key, or gets a certificate signed by a CA that clients don't trust, the verification fails. The browser flags the connection.

Attacker's certificate
        ↓
Not signed by a trusted CA for that domain
        ↓
Verification fails
        ↓
Browser warns / connection rejected

The TLS Handshake

Knowing the theory is one thing. Seeing how it plays out during a connection is another. Here's a simplified TLS 1.3 handshake:

Client                              Server

ClientHello  ──────────────────────→
             ←────────────────────  ServerHello
             ←────────────────────  Certificate
             ←────────────────────  CertificateVerify
             ←────────────────────  Finished
Finished     ──────────────────────→

         Encrypted application data
         ←─────────────────────────→

ClientHello: The client sends its supported protocol versions, cipher suites, and key-share information for the key exchange.

ServerHello: The server selects the protocol version and cipher suite, and responds with its own key-share contribution. At this point, both sides have enough information to derive shared secrets. The key exchange happens through a scheme like ECDHE, where both sides contribute values that allow them to compute a shared secret independently without ever transmitting the secret itself.

Certificate: The server sends its certificate chain so the client can authenticate the server's identity. The client validates the chain against its trust store, checks the certificate's validity period, and verifies that the domain name in the certificate matches the server being connected to.

CertificateVerify: This is the step most explanations skip, and it's important. The certificate proves that some trusted authority bound a public key to a domain. But it doesn't prove that the server currently possesses the corresponding private key. An attacker who obtained a copy of someone's certificate but not their private key could present that certificate.

CertificateVerify closes this gap. The server signs the handshake transcript so far using its private key. The client verifies this signature against the public key in the certificate. A valid signature proves that whoever is running this server possesses the private key, not just the certificate.

Finished: Both sides send a Finished message that covers the entire handshake transcript. This verifies that neither side's view of the handshake has been tampered with, and that both have derived the same session keys.

Why Symmetric Encryption Handles the Data

Public-key operations are computationally expensive. Encrypting every byte of application data with asymmetric cryptography would be impractically slow for most connections.

The handshake solves this elegantly. The key exchange produces shared secret material from which the connection derives symmetric session keys. Those keys are used for all subsequent application data.

Handshake key exchange
        ↓
Shared secret
        ↓
Symmetric session keys
        ↓
Fast symmetric encryption
        ↓
Application data

Public-key cryptography does the authentication and key agreement. Symmetric cryptography does the heavy lifting on the actual data. This separation is a deliberate design choice.

Why the MITM Now Fails

Return to the original attack. An attacker sitting between Alice and the server wants to substitute their own key.

Without TLS, they can. Alice receives the attacker's key, encrypts to it, and the attacker decrypts the traffic.

With TLS:

Alice
  ↓
Receives certificate
  ↓
Verifies chain against trust store
  ↓
Confirms domain matches
  ↓
Verifies CertificateVerify signature
  ↓
Proves server holds the private key
  ↓
Session established

For the attacker to impersonate the server, they'd need a certificate for the target domain that chains to a trusted CA, and the private key corresponding to the public key in that certificate. A fraudulent certificate from a CA that clients don't trust fails at the verification step. A valid certificate without the matching private key fails at CertificateVerify.

The MITM position doesn't help anymore. Observing the traffic reveals ciphertext encrypted under session keys the attacker doesn't have. Injecting their own certificate fails certificate verification. The attacker is stuck.

What TLS Doesn't Cover

TLS protects data in transit between authenticated endpoints. It doesn't protect against a compromised server, malicious code already running on the client, stolen private keys, or data after it's been decrypted at the destination. A padlock in the browser means the connection to that server is authenticated and encrypted. It says nothing about what the server does with your data once it arrives.

TLS doesn't solve the MITM problem by adding encryption. It solves a harder problem first: establishing who you're actually communicating with before that encryption can be trusted.

Certificates bind identities to public keys. Certificate Authorities create a chain of trust the client can verify. The TLS handshake authenticates the server, proves private-key possession, and negotiates shared secrets through key exchange. Symmetric encryption protects the connection efficiently from there.

That's what happens in the moment between typing a URL and the page loading. It's fast enough to feel instantaneous and careful enough that an attacker sitting on the network between you and the server can't impersonate either side.

What Is IDOR? How Can Changing an ID Expose Someone Else's Data?

Aditya Sharma — Sun, 06 Sep 2026 10:58:11 +0000

You're logged into an e-commerce site. You just placed an order, and the confirmation page shows:

GET /api/orders/1042

The server returns your order details. Everything looks normal.

Now consider what happens if you change that number:

GET /api/orders/1043

If the server returns that order too, without checking whether you're actually allowed to see it, that's the vulnerability. Not the fact that you changed the number. The fact that the server didn't notice you shouldn't have access to what came back.

This is Insecure Direct Object Reference, commonly called IDOR, or under the more precise modern framing, Broken Object Level Authorization (BOLA). The names describe the same underlying problem: an application that authenticates who you are but fails to verify whether you're authorized to access the specific object you're asking for.

Authentication Is Not Authorization

These two concepts get conflated constantly, and that conflation is where IDOR lives.

Authentication answers one question: who is this user? When you log in, the application establishes your identity. Your session token or cookie says "this request is from Alice."

Authorization answers a different question: what is Alice allowed to do? More specifically for IDOR: is Alice allowed to perform this operation on this particular object?

Alice
  ↓
Authenticated ✓
  ↓
Can access:
  Order 1042 ✓  (Alice's order)
  Order 1043 ✗  (Bob's order)

An application that correctly performs authentication but skips or misses authorization at the object level will happily hand Alice Bob's data, because all it checked was whether Alice was logged in.

What "Direct Object Reference" Actually Means

An object reference is just an identifier that lets the application locate something: a database row, a file, a resource. The identifier itself isn't the problem.

GET /users/42
GET /orders/1042
GET /invoices/781
GET /documents/a3f9...

These are all direct references. They're efficient and normal. The security question is what the server does when it receives one.

A vulnerable application treats possession of the reference as sufficient permission:

@app.get("/orders/<order_id>")
def get_order(order_id):
    order = db.get_order(order_id)
    return order

The application fetches whatever order matches the ID and returns it. It never asks whether the currently authenticated user is allowed to see that order. If you can construct or guess a valid ID, you can retrieve the corresponding object.

The fix is conceptually simple:

@app.get("/orders/<order_id>")
def get_order(order_id):
    order = db.get_order(order_id)

    if order.user_id != current_user.id:
        return forbidden()

    return order

Now the server checks that the object belongs to the requesting user before returning it. Unauthorized requests get a 403, not someone else's data.

The Bug Often Lives in the Query

One level deeper: authorization bugs frequently appear not in request handlers but in the data-access layer. The database query itself may be the right place to enforce scope.

Compare these two queries:

SELECT * FROM orders WHERE id = ?

versus:

SELECT * FROM orders
WHERE id = ?
AND user_id = ?;

The first retrieves any order matching the ID. The second retrieves an order only if it belongs to the current user. An unauthorized ID simply returns no rows, which the application can treat as a not-found or forbidden response.

Scoping queries to the current user's context makes authorization a property of data retrieval rather than a separate check that can be forgotten. It also means that if an authorization check is accidentally skipped somewhere in the application, the query itself doesn't return objects the user isn't allowed to see.

Unpredictability Is Not Authorization

A common response to IDOR vulnerabilities is to make IDs harder to guess. Instead of sequential integers, use UUIDs or opaque tokens:

/orders/7f3a92b4-e1d8-4c2a-bf19-3a8d1c7e05f6

This makes brute-force enumeration harder. It doesn't fix the underlying problem.

If the server still returns an order to any authenticated user who knows its ID, the authorization check is still missing. An attacker who obtains a UUID through another means, from a shared link, an API response, a log entry, simply uses it. Unpredictability raises the bar for unauthenticated access. It is not a substitute for checking whether the authenticated user is allowed to access a specific object.

This matters because it shifts developer thinking away from the real fix. The question isn't "how hard is the ID to guess?" It's "does the server verify that this user is allowed to access this object?"

Read Operations Are Not the Only Risk

IDOR isn't limited to GET requests. Object-level authorization applies across every operation:

GET    /api/orders/1042   → view
PUT    /api/orders/1042   → modify
DELETE /api/orders/1042   → delete

An application might correctly protect reads while leaving writes unguarded, or correctly protect deletion while leaving modification open. Each operation needs its own authorization check against the specific object being acted on. The underlying question is always the same: is this user allowed to perform this particular action on this particular object?

Client-Side Controls Don't Count

A frontend application might hide an edit button for objects the user doesn't own, or not display other users' orders in the UI. This provides no security.

An attacker communicates directly with the API, not through the browser's rendered UI. The fact that your application doesn't show a delete button to unauthorized users has no bearing on what happens when an unauthorized user sends a DELETE request directly.

Browser UI (hides unauthorized controls)
         ↓
Direct API request (bypasses the UI entirely)
         ↓
Authentication check
         ↓
Object lookup
         ↓
Authorization check ← this must exist on the server
         ↓
Response

The authorization check belongs in the server. Everything the frontend does is presentation. None of it enforces security.

Building Authorization That Holds

The defensive pattern follows from the mechanism. For every request that accesses a specific object, the server needs to establish three things: who is making the request, what object is being accessed, and whether that user is permitted to perform the requested operation on that object.

Authenticated user
        +
Requested object
        +
Requested action
        ↓
Authorization decision

One practical approach is to scope data access to the current user's context at the query level, as shown earlier. Another is to centralize authorization logic rather than scattering ad-hoc permission checks across individual endpoints, where they're easy to miss or apply inconsistently.

Testing also matters. Authorization bugs are invisible to tests that only check "authenticated users can access this endpoint." Tests need to verify that User A cannot access User B's objects, cannot modify User B's objects, and cannot delete them. The test cases that catch IDOR are specifically the cross-user ones.

Changing /orders/1042 to /orders/1043 isn't the vulnerability. If the server enforces authorization correctly, that request returns a 403. The vulnerability is what the server does when it retrieves an object without verifying the requesting user's permission to access it.

Authentication tells the application who you are. That's a necessary first step. Authorization tells the application what you're allowed to do. Object-level authorization goes one step further: it asks whether you're allowed to do it to this specific object.

IDOR happens in the gap between the first check and the third. Closing that gap is the entire fix.

How Can Google Maps Find the Shortest Route So Fast?

Aditya Sharma — Sun, 06 Sep 2026 07:17:45 +0000

You type two addresses into a navigation app. Within a fraction of a second, it returns a route. Not an approximate one. The shortest one, accounting for real road constraints, distances, and travel times.

The road network it searched could span an entire continent. The graph underlying Europe's road network alone has hundreds of millions of nodes and edges. So how does the system search it so quickly?

The answer isn't one clever algorithm. It's a progression of improvements, each one shifting more work from query time to preprocessing, until the actual online search becomes almost trivially small.

The Graph Underneath

A road network maps naturally onto a weighted directed graph. Intersections become nodes. Roads become edges. Travel time or distance becomes the edge weight. Finding the fastest route between two places becomes finding the minimum-cost path between two nodes.

The challenge is that this graph is enormous, and the number of possible paths through it grows fast. Brute force, trying every possible route to find the best one, is completely impractical. The problem isn't finding a route. It's finding the optimal route without exploring most of the graph.

Dijkstra's Algorithm

The first serious solution is Dijkstra's algorithm. It works with non-negative edge weights, which road networks satisfy, and it's guaranteed to find the optimal path.

The mechanics are straightforward. Dijkstra maintains the best-known distance to every node, initially infinity for all except the source, which starts at zero. At each step, it selects the unvisited node with the lowest current distance, then relaxes its outgoing edges: for each neighbor, if the path through the current node is cheaper than what we've recorded, we update the neighbor's distance. A priority queue makes selecting the cheapest unvisited node efficient.

Source: A, Destination: F

Initial distances: A=0, B=∞, C=∞, D=∞, E=∞, F=∞

Step 1: Visit A, relax neighbors → B=4, C=2
Step 2: Visit C (cheapest), relax neighbors → D=5, E=8
Step 3: Visit B, relax neighbors → D=4 (updated)
...until F is settled

The problem is that Dijkstra expands outward from the source in all directions simultaneously. To find the route from London to Edinburgh, it might settle nodes across most of England before reaching Edinburgh. For queries spanning a large area, the search region grows enormous.

A* Guides the Search

A* improves on Dijkstra by adding a heuristic that estimates how promising each node is relative to the destination.

f(n) = g(n) + h(n)

Where g(n) is the cost from the source to node n, and h(n) is an estimate of the remaining cost from n to the destination. A* prioritizes nodes with lower f(n) values, guiding the search toward the destination rather than expanding uniformly.

For road networks, straight-line geographic distance is an intuitive heuristic: a node geographically closer to the destination is plausibly a better candidate to explore next. For the heuristic to guarantee an optimal solution, it must be admissible: it must never overestimate the true remaining cost. Straight-line distance works because real roads are never shorter than straight lines.

A* can dramatically reduce the number of nodes visited compared to Dijkstra. But it still operates on the entire road graph and can be slow for long-distance queries where the heuristic doesn't guide the search effectively.

Bidirectional Search

Another improvement is running two simultaneous searches: one forward from the source, one backward from the destination. Both searches expand inward, and they meet somewhere in the middle.

Source ──────────→ meeting region ←────────── Destination

This reduces the search region compared to a single-direction Dijkstra, though the savings depend on graph structure and the query. The technical details of when the bidirectional searches are terminated and how the optimal meeting point is identified require care to get right.

Bidirectional search is useful, but it still operates on the unmodified graph. Which brings us to the more fundamental question:

What if we could do most of the expensive work before the user ever asks for directions?

Contraction Hierarchies

Contraction Hierarchies are built on a different insight. Instead of making each query search faster on the same graph, preprocess the graph so that future queries search a much smaller, smarter structure.

The first step is assigning an importance ordering to nodes. Some intersections are genuinely more important for long-distance travel than others. A residential dead-end street is barely relevant. A major motorway junction might sit on the optimal path for millions of routes. The exact ranking uses metrics like edge difference: how many shortcut edges would need to be added if this node were removed.

Once nodes are ranked, the algorithm contracts them in order from least to most important.

When a node B is contracted, it's temporarily removed from the graph. If the shortest path between any pair of B's neighbors went through B, and no alternative path of equal or lesser cost exists, a shortcut edge is added directly connecting those neighbors:

Before contracting B:
A ──(3)──→ B ──(2)──→ C

After contracting B:
A ──────────(5)──────→ C   (shortcut)

Crucially, before adding each shortcut, the algorithm runs a witness search: a limited Dijkstra that checks whether another path already connects those neighbors with the same or lower cost. If such a path exists, the shortcut isn't needed. This keeps the graph from bloating with redundant shortcuts.

The important point: contracting a node doesn't delete information. It replaces multi-hop paths through unimportant nodes with direct shortcut edges, preserving all relevant shortest-path distances.

After all contractions, the graph has an upward structure. Every edge points from a less important node to a more important one.

Why This Changes the Query

Preprocessing transforms the problem. During a query:

A bidirectional search runs on the contracted graph.
The forward search from the source follows only upward edges, moving toward increasingly important nodes.
The backward search from the destination does the same.
Both searches climb the hierarchy and meet near the top.

Local streets
     ↓
Minor intersections
     ↓
Major junctions
     ↓
Regional highways
     ↓
Major motorways

The forward and backward searches climb this hierarchy, meet near the top, and the optimal path is reconstructed by unpacking the shortcuts.

The search doesn't have to explore local streets across the entire graph. It quickly ascends to important nodes and meets the backward search. Instead of settling millions of nodes, the query might settle thousands.

This is the key insight: Contraction Hierarchies don't make Dijkstra magically faster. They change the graph that the query has to search.

Preprocessing vs Query Time

The two costs are fundamentally different:

Preprocessing (offline, done once):

Rank nodes by importance
Contract nodes in order
Run witness searches
Add shortcut edges
Build the hierarchical graph structure Query (online, runs millions of times):
Receive source and destination
Run bidirectional hierarchical search
Unpack shortcuts to reconstruct the route Preprocessing is expensive. It might take minutes for a continental road network. But it happens once. The millions of queries that follow operate on a structure designed to make them cheap.

This is a general engineering principle that goes beyond routing: the fastest online computation is often the computation you moved offline.

Some routing systems extend this further with Customizable Contraction Hierarchies (CCH), which separate the topology-dependent preprocessing from the weight-dependent parts. Road topology changes slowly, but edge weights change constantly due to traffic and road conditions. CCH allows the metric-sensitive parts of preprocessing to be updated quickly without rerunning the full contraction.

Modern road-routing systems use techniques such as Contraction Hierarchies and related hierarchical routing methods. The exact approach used in production systems like Google Maps or Apple Maps isn't publicly documented in full detail, but hierarchical preprocessing is well-established in the academic literature and widely used in practice.

The progression from brute force to Contraction Hierarchies isn't a series of marginal improvements. Each step changes what the algorithm is actually doing:

Brute force → try everything

Dijkstra → search optimally but expands too far

A* → guide the search toward the destination

Bidirectional → search from both ends

Contraction Hierarchies → preprocess the graph so queries barely have to search it

The impressive part isn't any single algorithm. It's the realization that you can invest heavily in offline work to make the online problem almost trivially small. A query that once required exploring millions of nodes can be answered by exploring thousands, because the expensive structural work already happened before you ever asked the question.

What Is a Digital Signature? How Can You Prove a Message Wasn't Changed?

Aditya Sharma — Sat, 05 Sep 2026 07:44:13 +0000

You download a software package from the internet. The website tells you it's the official release from the expected publisher. But how do you actually know that? The file could have been modified in transit, or the server could have been compromised, or you could be downloading from a mirror you don't fully trust.

A checksum helps with one part of this. If the publisher posts a SHA-256 hash of the file, you can download the file, compute its hash, and compare. If the hashes match, the file wasn't corrupted or modified after the hash was published.

But there's a problem: the hash itself has the same authenticity problem as the file. If an attacker can replace the file, they can replace the published hash too. A hash tells you whether something changed. It doesn't tell you who computed it.

Digital signatures solve the authenticity half of this problem.

Why Hashing Alone Isn't Enough

A cryptographic hash function takes an arbitrary input and produces a fixed-size digest. Change a single byte in the input and the digest changes completely. That property is useful for detecting modification.

Message
   ↓
SHA-256
   ↓
256-bit digest

But anyone who has the message can compute its hash. There's nothing in the hash itself that proves who created it or that it came from a specific source. For that, you need something only one party can produce: a private key.

Signing a Message

The signing process goes like this:

Message
   ↓
Hash function
   ↓
Message digest
   ↓
Private key + signature algorithm
   ↓
Digital signature

The signer computes a cryptographic hash of the message first. That digest is a compact, fixed-size representation of the message content. Then a signature algorithm uses the signer's private key to produce a signature over that digest.

The reason for hashing before signing is practical: messages can be arbitrarily large, but the digest has a fixed size regardless of input length. The signature algorithm operates on the digest rather than the original message. This is efficient, and because a secure hash function makes it computationally infeasible to find two inputs with the same digest, signing the digest is equivalent to signing the message.

One thing to be precise about: producing a digital signature is not the same as encrypting the message with a private key. That description is a common oversimplification and it's wrong in a way that matters. Digital signatures use signature algorithms designed specifically for this purpose. The output is a signature, not ciphertext, and the process is conceptually different from encryption.

How Verification Works

A verifier has three things: the message, the digital signature, and the signer's public key.

Received message ──→ Hash ──────────────────────┐
                                                 ▼
Digital signature ──→ Public key ──→ Verification result

The verifier hashes the received message to produce a digest. The signature verification algorithm uses the public key to check whether the signature is valid for that digest. If the message was altered after signing, the digest computed by the verifier won't match what was signed. Verification fails. If the signature was produced by a different private key than the one corresponding to the provided public key, verification fails.

A valid verification result means two things: the message has not been modified since it was signed, and the signature was produced by whoever holds the corresponding private key. The public key can be distributed freely. It cannot be used to derive or reconstruct the private key in a properly designed system.

Integrity and Authenticity Are Separate Properties

A digital signature provides both integrity and authenticity, but they're worth distinguishing.

Integrity means the signed data hasn't changed. A properly designed signature scheme uses a hash function where even a one-bit modification to the message causes verification to fail.

Authenticity means the signature was produced by the holder of a specific private key. This is more subtle than it might seem. A valid signature proves control of a private key. It doesn't automatically prove the real-world identity of the person holding that key. Identity binding requires additional infrastructure.

This Is Not Encryption

Digital signatures are often conflated with encryption, especially in casual descriptions. They're different mechanisms with different goals.

Encryption provides confidentiality: only the intended recipient can read the content. A digital signature provides integrity and authenticity: anyone with the public key can verify that the signature is valid for that message. Signing a message doesn't hide it. If you want both authenticity and confidentiality, you need both signing and encryption, and they're applied separately.

Non-repudiation is sometimes associated with digital signatures: if only one party holds a private key and a valid signature exists under the corresponding public key, it's difficult for that party to deny having signed the message. But non-repudiation as a legal or practical guarantee depends on key control, identity binding, and surrounding evidence. It's a useful property, not an automatic absolute guarantee.

Signature Algorithms in Practice

Three signature schemes are worth knowing by name.

RSA-PSS is a signature scheme based on RSA. Modern RSA signing should use an appropriate padding and signature construction like PSS rather than naive textbook RSA. The underlying RSA key pair supports both signing and encryption, but those are distinct operations.

ECDSA (Elliptic Curve Digital Signature Algorithm) produces signatures using elliptic-curve cryptography. It achieves comparable security to RSA with significantly shorter key lengths.

Ed25519 is a modern elliptic-curve signature scheme built on the Edwards curve. It's fast, produces short signatures, and has a simpler security model than ECDSA. It's widely used in SSH keys, TLS, and secure messaging protocols.

These schemes have different mathematical constructions and different performance characteristics. They don't work identically internally, but they serve the same conceptual purpose.

Knowing Whose Key to Trust

A digital signature proves that a specific private key produced the signature. But knowing that a signature is cryptographically valid doesn't tell you whose key you're trusting.

Certificates solve this by binding a public key to an identity using a signature from a trusted certificate authority. When your browser validates an HTTPS connection, it's checking that the server's public key is certified by a CA your browser trusts. The certificate is itself a signed document: the CA's signature over the server's public key and identity information.

Software signing works similarly. Operating system package managers, code signing for mobile apps, and signed Git commits all rely on some mechanism for trusting a public key in the first place.

Private Key Security

The security of a digital signature scheme depends on the private key remaining private. If an attacker obtains the private key, they can produce signatures that verify successfully under the corresponding public key. The signatures would be cryptographically indistinguishable from legitimate ones.

This is why private keys are protected carefully, stored in hardware security modules, rotated when compromised, and revoked through certificate revocation mechanisms when necessary. The cryptography is sound; the operational security around key management is where things go wrong in practice.

The private key creates a signature over a digest of the message. The public key lets anyone verify that signature against the message. If the message changes, the digest changes, and verification fails. If the signature came from a different private key, verification fails.

That's the entire mechanism. The layers on top, certificates, trust hierarchies, revocation, key management, all exist to answer the question the signature itself can't answer: whose key is this, and should you trust it?

What Is CSRF? How a Website Can Make Your Browser Send a Request

Aditya Sharma — Fri, 04 Sep 2026 08:02:46 +0000

You're logged into your bank. The session is active, the authentication cookie is sitting in your browser. You open another tab and visit an unrelated website. That website causes your browser to send a POST request to your bank.

Your browser attaches the bank's authentication cookie automatically. The bank receives what looks like an authenticated request. It processes it.

You didn't initiate that request. But your browser did, using your credentials.

That's Cross-Site Request Forgery. The name describes the mechanism precisely: a request is forged, it's cross-site in origin, and it exploits the fact that your browser carries your credentials wherever it goes.

Why the Browser Does This

Cookies are scoped to domains. When your browser makes a request to a domain, it includes that domain's eligible cookies automatically. This is normal behavior, not a bug. It's what keeps you logged into websites as you navigate around.

The browser doesn't distinguish between:

a request you consciously initiated by clicking a button
a request triggered by JavaScript on a page you're viewing
a request caused by a resource on another website From the browser's perspective, a request to bank.com gets bank.com's cookies. The origin of the request, which page caused it, is not reflected in those credentials.

The server receives the HTTP request and sees valid authentication. It has no way to know, based on the cookie alone, whether you meant to send that request.

Legitimate request:

Browser
   ↓
POST /change-email  +  authentication cookie
   ↓
Application

CSRF scenario:

Other website
   ↓
Triggers request from victim's browser
   ↓
POST /change-email  +  authentication cookie
   ↓
Application (sees valid credentials)

The attacker doesn't need to steal the cookie. They don't need to read the response. The goal is simply to cause a state-changing request to happen using the victim's existing session.

Authentication Is Not the Same as Intent

This is the core of the problem.

Authentication tells the server who is making the request. A valid cookie establishes that the request comes from an authenticated session. But authentication says nothing about whether the user actually intended to perform the action.

When a server receives a POST to /transfer with a valid authentication cookie, it knows the request is associated with a logged-in account. It does not know whether the account holder clicked a button, or whether another website silently triggered that request in the background.

CSRF exploits the gap between those two things. The credentials are genuine. The request was not.

CSRF Tokens

The standard defense against CSRF is introducing something the attacker cannot obtain: an unpredictable token tied to the user's session.

<form action="/change-email" method="POST">
    <input type="hidden" name="csrf_token" value="k9Zm3...">
    <input type="text" name="email">
    <button type="submit">Update Email</button>
</form>

The server generates this token and associates it with the user's session or request context. The legitimate application page includes the token in the form. When the form is submitted, the server checks that the token is present and valid before processing the request.

The reason this works comes down to browser same-origin restrictions. A page on another domain cannot read the content of your application's pages. It can cause your browser to send a request to the application, but it cannot read the token embedded in the form. Without the token, the forged request fails the server's check.

Implementations vary. The classic approach stores a token in the session and verifies it server-side. Stateless patterns like signed double-submit cookies avoid server-side state entirely. Both separate "authenticated request" from "request carrying evidence it came from our own page."

SameSite Cookies

Modern browsers support a SameSite attribute on cookies that controls whether they're sent with cross-site requests.

SameSite=Strict prevents the cookie from being sent with any cross-site request, including navigations. Clicking a link from another site to your banking dashboard would not send the session cookie.

SameSite=Lax is more permissive. Cookies are sent with top-level navigation requests like clicking a link, but not with cross-site subresource requests like forms or fetches triggered by another page. Many browsers now use Lax as the default when SameSite is not explicitly set.

SameSite=None sends the cookie with all cross-site requests, which requires Secure and is used for contexts that genuinely need this behavior.

SameSite=Lax or Strict can significantly reduce CSRF risk because the browser simply won't attach the session cookie to forged cross-site requests. But SameSite is a browser-level mitigation. Relying on it alone without application-level token validation isn't a complete approach, both because browser behavior isn't fully uniform across every scenario and because defense in depth matters.

Origin and Referer Headers

Servers can also inspect the Origin and Referer headers to check where a request came from. A state-changing request arriving from an unexpected origin is a signal worth acting on.

These checks add another layer, but they come with caveats. Neither header is guaranteed to be present on every request. Referer can be stripped by privacy settings or browser behavior. These checks work best as part of a defense-in-depth approach alongside CSRF tokens and appropriate cookie settings, not as the sole defense.

CSRF and XSS Are Different Threats

Since XSS came up in the previous article, the comparison is worth making explicit.

XSS introduces attacker-controlled content into the victim's browser in the application's own origin, where it can run as part of the page. CSRF causes the victim's browser to make a request to a target application from a different origin, exploiting automatic credential attachment.

One important connection: XSS can undermine CSRF defenses within the affected application. If attacker-controlled JavaScript executes in the application's origin, it may be able to read CSRF tokens, make requests with those tokens attached, and bypass the protection entirely. Fixing XSS and CSRF vulnerabilities are separate efforts, but XSS in an application can render its CSRF mitigations ineffective.

Bearer Tokens and the CSRF Threat Model

APIs that require an explicit authorization header rather than a cookie work differently:

Authorization: Bearer <token>

The browser doesn't automatically attach authorization headers to cross-site requests the way it does with cookies. Another site can cause your browser to send a request, but it cannot cause that request to include a bearer token it doesn't have access to.

This changes the CSRF threat model. If authentication requires JavaScript to explicitly retrieve and attach a token that another origin cannot access, the traditional cookie-based CSRF attack doesn't apply in the same way.

But this doesn't make bearer tokens unconditionally safe from CSRF. Security properties depend on where the token is stored, how it's obtained, and the application's overall design. The broader point is that CSRF risk is closely tied to the authentication mechanism and what the browser supplies automatically.

CSRF works because browsers carry credentials on behalf of the user, and servers can't always tell the difference between a request the user intended and one they didn't.

A session cookie proves authentication. It doesn't prove intent. The defenses, CSRF tokens, SameSite cookies, origin checks, all exist to give the server something that proves the request actually originated from its own trusted context.

Authentication and intent are different things. CSRF is what happens when a server treats them as the same.

What Is SQL Injection? How User Input Can Become a Database Command

Aditya Sharma — Thu, 03 Sep 2026 04:43:34 +0000

Consider a login form. A user enters a username and password. Somewhere behind that form, the application needs to ask the database whether those credentials exist. A straightforward query for that looks something like this:

SELECT * FROM users
WHERE username = 'alice'
AND password = '...';

The application constructs that query, sends it to the database, and if a matching row comes back, the user is authenticated. This works. The problem starts with how the query gets constructed.

When Strings Become SQL

The simplest way to build that query is also the most dangerous: concatenate the user's input directly into the SQL string.

query = "SELECT * FROM users WHERE username = '" + username + "'"

When username is alice, the resulting query is sensible SQL. But the database doesn't see username; it sees the final string. It has no idea which characters came from the developer's query template and which came from the user's input. Once the string is assembled, it's all just SQL.

This is where the boundary breaks down.

If a user provides input that contains characters meaningful in SQL syntax, those characters don't stay inside the "data" portion of the query. They become part of the SQL itself. The application intended for the value to be a data literal. The database receives something with a different structure.

This is SQL injection: user-controlled input influences the SQL syntax rather than remaining data within it.

The parallel to XSS is direct. In XSS, untrusted data reaches the browser in a context where it becomes executable markup. In SQL injection, untrusted data reaches the database in a context where it becomes part of a command. The failure mode is the same: a boundary between data and executable instructions has been lost.

The Real Fix: Parameterized Queries

The solution isn't to scan input for suspicious characters and filter them out. The solution is to never combine the SQL structure and the user-supplied values into a single string in the first place.

Parameterized queries do this by separating the two:

query = "SELECT * FROM users WHERE username = ?"
cursor.execute(query, (username,))

The query template defines the SQL structure. The value is supplied separately. The database driver handles them as distinct things: the structure tells the database what kind of query this is, and the value is data to be used within that structure.

This isn't the database "detecting suspicious input." It's a different communication model entirely. Because the structure and the values are never combined into one string, there's no opportunity for user input to alter the query's shape. The username is always treated as a value to match against a column, regardless of what characters it contains.

Placeholder syntax varies between databases and drivers. Some use ?, others use %s or named parameters like :username. The specific syntax is a detail; the principle is the same across all of them.

Prepared Statements

Prepared statements extend this idea further. The application sends the query template to the database first, the database parses and compiles it, and then values are supplied for execution. The SQL structure is fixed before any user data enters the picture.

The practical effect is similar to parameterized queries: values are always data, never syntax. Some database systems also allow reusing a prepared statement across multiple executions with different values, though that's more of a performance consideration than a security one.

ORMs and Query Builders

Modern ORMs and query builders often parameterize values automatically. When you call something like User.where(username: params[:username]) in an ORM, the library typically handles the parameterization for you. The generated SQL keeps structure and values separate.

But using an ORM doesn't automatically make an application immune to SQL injection. Most ORMs also provide ways to drop into raw SQL when needed. If a developer constructs a raw query with concatenated input through an ORM's escape hatch, the vulnerability is still there. The abstraction helps when you use it correctly; it doesn't protect against deliberately bypassing it.

Why Validation Isn't Enough

Input validation is worth doing. Ensuring that a username only contains letters and numbers, for instance, limits what can be submitted and may reduce certain attack surfaces. But validation is not the fundamental defense against SQL injection.

Validation works at the application level by restricting what input is accepted. Parameterized queries work at the query level by ensuring that whatever is accepted can never alter SQL structure. These are different guarantees. An application that validates inputs but constructs queries through concatenation is still vulnerable if the validation has gaps, or if the attacker finds a legitimate input that's still useful for injection purposes.

The safe path is parameterization first, with validation as an additional layer.

The Boundary That Has to Hold

SQL injection is not really about databases being insecure, or about users being malicious, or about any specific characters being dangerous. It's about what happens when an application assembles a command from a template and external input by treating both as the same kind of string.

The database receives one SQL statement. It parses that statement and executes it. It has no visibility into how the statement was assembled or which parts the developer intended as structure versus which parts a user supplied. If those two things were combined into the same string, the database can't separate them.

Parameterized queries don't give the database better judgment. They change the interface so the developer never has to combine them in the first place. The SQL structure and the user-supplied values travel separately, and the database handles them as separate things.

The problem isn't that users are allowed to enter text. The problem is allowing that text to become part of the program's command language. Keeping data as data, and keeping SQL as SQL, is the entire fix.

What Is Cross-Site Scripting (XSS)? Understanding a Critical Web Security Vulnerability.

Aditya Sharma — Wed, 02 Sep 2026 06:53:09 +0000

Imagine a website where users can post comments. Someone submits this as their comment:

<script>
    alert("Hello");
</script>

If the application takes that input and places it directly into the HTML it serves to other users, the browser doesn't see a comment. It sees a script tag. The vulnerability isn't that JavaScript exists on the page. JavaScript belongs on web pages. The problem is that untrusted user input ended up in a context where the browser interpreted it as executable content rather than inert text.

The Core Problem

A browser rendering a webpage doesn't distinguish between HTML the developer wrote and HTML that arrived through a comment field. It parses what it's given. If user input gets embedded into the page without being handled carefully, the browser processes it the same way it processes everything else.

User Input
    ↓
Web Application
    ↓
HTML / DOM
    ↓
Browser
    ↓
Input interpreted as executable content

Untrusted data should remain data. XSS occurs when the application allows that data to cross into a context where the browser interprets it as code or executable markup. The boundary between "string containing angle brackets" and "HTML the browser will parse" is where the vulnerability lives.

Three Forms of XSS

XSS shows up in a few different ways depending on where the injection happens and how the input travels.

Stored XSS is when untrusted input gets saved to a database and later served to other users. The comment example above is stored XSS. An attacker submits input once, and every user who views that page subsequently receives it. The application acts as an unwitting distribution mechanism.

Reflected XSS involves input that isn't stored but gets reflected back in an immediate server response. Search pages are a common example: if a query is echoed into the page as "You searched for: [query]" and the query isn't handled carefully, an attacker can craft a URL whose query parameter contains a payload. When another user visits that URL, the server reflects the input back in the response without the browser having any way to know it didn't come from the developer.

DOM-based XSS is different in that no server-side injection is required. The server sends a perfectly safe response, but client-side JavaScript reads from an attacker-controlled source, such as a URL fragment or a query parameter, and places it into an unsafe DOM context without appropriate handling. The server does not need to store or reflect the payload; the vulnerability exists entirely in how the client-side code processes data.

Why `innerHTML` Matters

This is where the mechanism becomes most concrete for web developers.

element.innerHTML = userInput;

When you assign to innerHTML, you're asking the browser to parse the string as HTML. Attacker-controlled markup can therefore create elements or attributes that introduce executable browser contexts. An image element with an onerror handler, for example, doesn't require a <script> tag at all:

element.innerHTML = '<img src="x" onerror="/* runs here */">';

The string has become markup, and the browser treats it accordingly.

element.textContent = userInput;

textContent is different. It assigns the string as plain text. Angle brackets are treated as literal characters, not HTML. Whatever the user submitted appears on the page as written, not as parsed markup.

The distinction isn't that innerHTML is inherently dangerous. innerHTML is a legitimate API, and assigning developer-controlled or appropriately processed content through it is fine. The risk arises specifically when untrusted input flows into it without being handled: the browser cannot tell that the string originated from a user rather than the application, so it parses it all the same.

Frameworks and Where XSS Still Appears

Modern frontend frameworks generally escape interpolated content by default. When you render a variable in a React component or an Angular template, the framework treats it as text rather than HTML, preventing ordinary variables from being interpreted as markup.

But frameworks provide explicit ways to opt out of this. React has dangerouslySetInnerHTML. Angular has bypassSecurityTrustHtml. These APIs exist for legitimate use cases where rendering HTML is genuinely necessary. When developers use them with untrusted input, they've deliberately stepped outside the safe defaults the framework was providing.

The important point is that frameworks reduce the surface area for XSS by making the safe path the default path, but they don't eliminate the possibility. Developers can still create unsafe data flows when they work around framework protections, or when they use lower-level DOM APIs directly.

Defenses

Output encoding is the primary defense. When user-supplied data is placed into HTML, JavaScript, CSS, or a URL, it should be encoded appropriately for that context so the browser treats it as data rather than code. The encoding rules differ by context: what's safe to leave unescaped inside an HTML attribute is different from what's safe inside a JavaScript string. Treating all output encoding as a single uniform operation misses this.

Safe DOM APIs are the practical expression of this for client-side code. textContent is safe for plain text because it doesn't invoke HTML parsing. Building DOM nodes programmatically with createElement and setting their properties explicitly avoids the risk of parsing an arbitrary HTML string, though safety still depends on what's assigned to those properties afterward.

Framework-provided escaping is useful because it pushes the safe default into the rendering layer, so developers get protection without having to remember to apply encoding manually on every interpolated value.

Content Security Policy is defense in depth. A strong CSP can tell the browser which scripts are permitted to run, limiting the impact of a successful injection. It doesn't remove the underlying vulnerability; if untrusted input is making it into an executable context, CSP is constraining the damage rather than preventing the injection. It's a meaningful layer, but not a substitute for fixing the root cause.

Input validation is worth doing for many reasons, but it shouldn't be treated as the primary XSS defense. Validating that a field looks like an expected format doesn't guarantee that whatever passes validation is safe to insert into every possible output context. An application that validates inputs but then places them into the page without encoding is still vulnerable.

The browser has no way to know where a string came from. It doesn't know a piece of HTML arrived through a comment field rather than from the developer. It just parses what the application puts in front of it.

XSS is not a browser flaw, and it's not a problem with JavaScript. It's a failure to maintain the boundary between data and code. The application accepted input, and somewhere between accepting it and rendering it, that input crossed into a context where the browser would execute it.

Keeping that from happening is the whole job.

Stack vs Heap Memory: What Actually Happens When You Create a Variable?

Aditya Sharma — Tue, 01 Sep 2026 10:19:27 +0000

Look at this line:

int x = 10;

What actually happens when the program executes it? Somewhere in memory, space for an integer gets set aside, and the value 10 goes into it. But where in memory? And what decides when that space gets reclaimed?

The answer involves two different regions of memory that programs use for different purposes.

Program
   ↓
Memory
   ├── Stack
   └── Heap

The Stack

When your program calls a function, the runtime needs somewhere to put things: the function's local variables, the arguments passed to it, a record of where to return when the function finishes. All of this gets stored in a structure called a stack frame, and that frame lives on the stack.

void example() {
    int x = 10;
}

When example() is called, a frame is pushed onto the stack. x lives inside that frame. When example() returns, the frame is popped. The memory that held x is gone, or more precisely, it's considered free to be reused. You don't have to do anything to make that happen. The lifetime of x is tied to the lifetime of the function call.

This is why local variables work the way they do. They exist while the function is running and disappear when it's done. The stack grows and shrinks as functions are called and return, and the bookkeeping is simple: the runtime just maintains a pointer to the current top of the stack.

Allocation on the stack is cheap for this reason. Reserving space for a local variable is typically just adjusting that stack pointer by a fixed amount. No searching, no tracking, no negotiation with the operating system. The frame is there when you enter the function and gone when you leave.

The Heap

Some memory needs to outlive the function that created it. Maybe you're building a data structure that gets passed around. Maybe you don't know at compile time how much memory you'll need. The stack isn't designed for this. That's what the heap is for.

int *p = malloc(sizeof(int));
*p = 10;

malloc allocates memory on the heap and returns a pointer to it. That memory doesn't disappear when the current function returns. It persists until someone explicitly frees it, or in languages with garbage collection, until the runtime determines it's no longer reachable.

The pointer p itself might live on the stack. But what p points to lives on the heap. That distinction matters:

stack
┌──────────────┐
│      p  ──────────────┐
└──────────────┘        │
                        ↓
                      heap
                ┌───────────────┐
                │  int value    │
                └───────────────┘

This is a useful mental model, but treat it as conceptual. Different languages and runtimes manage this differently. The diagram is showing you the idea, not a literal memory map.

The tradeoff with heap allocation is that it's more work. The runtime has to find a suitable free region, track what's in use, and eventually reclaim memory when it's no longer needed. In C, you do that manually with free(). In Java or JavaScript, a garbage collector handles it. Either way, there's overhead that stack allocation doesn't have.

Why Both Exist

The stack is well-suited to local execution state: things that exist for the duration of a function call and nothing longer. Its automatic lifetime management is a feature, not a limitation.

The heap is well-suited to data with more flexible lifetimes: things that need to outlive the function that created them, or that need to be shared across different parts of a program, or whose size isn't known until runtime.

Most programs use both constantly. A function's local variables live on the stack. Objects created with new in Java, or allocated with malloc in C, live on the heap. References or pointers on the stack point into the heap.

Common Misconceptions

A few things that get oversimplified.

Not every local variable is guaranteed to live on the stack. Modern compilers can perform escape analysis: if they determine that a local variable doesn't escape the current function, they might keep it in a register rather than pushing it to memory at all. Conversely, if a variable does escape, the compiler might allocate it on the heap even if you wrote it as a local. The source code doesn't dictate the physical layout; the compiler and runtime do.

Not every object is guaranteed to live on the heap. Some languages and runtimes can allocate short-lived objects on the stack if they can prove it's safe. The distinction in source code between "stack variable" and "heap object" doesn't always map cleanly onto what actually happens.

Stack is not simply "fast" and heap is not simply "slow." Stack allocation is simpler, but whether that translates to a meaningful performance difference depends entirely on the workload. The more important factor for memory performance is usually cache behaviour, and that has more to do with access patterns than with which region the memory lives in. The stack is not the same thing as CPU cache.

Heap allocation doesn't necessarily mean the program talks to the operating system every time. Memory allocators like malloc typically request larger chunks of memory from the OS and then manage those chunks internally. Individual malloc calls usually don't cross the kernel boundary; they're served from a pool the allocator already has.

The mental model worth keeping:

Stack → function calls, local execution state, automatic lifetime
Heap  → dynamically managed memory with more flexible lifetime

These are useful conceptual categories. Where memory physically ends up, and how fast it is to access, depends on the language, the compiler, the runtime, and what the hardware decides to do with it. The stack and heap are real, but they're not rigid physical rules. They're a model for thinking about how programs manage memory, and like most models, they're most useful when you also know where they break down.

What Does `async/await` Actually Do in JavaScript?

Aditya Sharma — Mon, 31 Aug 2026 13:38:37 +0000

Most developers learn async/await as syntax that makes asynchronous code look synchronous. You await something, and the code below it runs after. It reads top to bottom, like normal code. That mental model is mostly fine for writing async functions, but it hides what's actually happening. And once you need to debug a weird execution order or understand why something runs when it does, the surface-level model breaks down.

The thing most people get wrong: await looks like it pauses execution. It doesn't. Not in the way you might think.

An async Function Is Just a Function That Returns a Promise

Start here, because everything else follows from it.

async function getData() {
    return 42;
}

getData() doesn't return 42. It returns Promise.resolve(42). Every async function wraps its return value in a Promise, whether you ask for it or not. If the function throws, the returned Promise rejects instead.

This matters because it means an async function, from the outside, is just a function that returns a Promise. The async keyword is doing two things: allowing await inside the function, and ensuring the return value is always a Promise.

What `await` Actually Does

When execution reaches an await expression, a few things happen.

async function getData() {
    console.log("A");

    const response = await fetch("/data");

    console.log("B");
}

console.log("A") runs synchronously. Then fetch("/data") is called, which returns a Promise. At the point of await, the async function suspends. Execution leaves getData and returns to whatever called it.

The key word is suspends, not blocks. The JavaScript thread is not sitting there waiting. It's free to do other things. The rest of the call stack continues. Other code can run. The event loop can process other tasks. getData is just paused at that line, waiting for the Promise to settle.

When the Promise from fetch eventually resolves, the continuation of getData, everything after the await- gets scheduled to run. The function picks up where it left off. console.log("B") runs.

The Thread Isn't Paused. The Function Is.

This is the distinction that matters most.

JavaScript is single-threaded. There is one call stack. When code is running, nothing else runs. await doesn't change this. It doesn't create a new thread. It doesn't run anything in the background. What it does is hand control back to the event loop while the current async function waits.

The event loop is part of the mechanism that allows JavaScript to process other scheduled work while an async function is suspended. It looks for work to do: callbacks from timers, I/O results, resolved Promises, user events. When a Promise that was being awaited settles, the continuation of the async function is scheduled as a microtask, and the event loop runs it once the current call stack is empty.

To see this clearly, look at what happens with an immediately resolved Promise:

async function test() {
    console.log("A");
    await Promise.resolve();
    console.log("B");
}

console.log("C");
test();
console.log("D");

You might expect: C, A, B, D. The actual output is: C, A, D, B.

Here's why. console.log("C") runs. test() is called. Inside test, console.log("A") runs. Then await Promise.resolve() is reached. The Promise is already resolved, but await still suspends the function. The continuation is scheduled as a microtask, not run immediately. Execution returns to the caller. console.log("D") runs. The current call stack is now empty. The event loop picks up the microtask. console.log("B") runs.

Even though the Promise was resolved instantly, the code after await didn't run synchronously. The continuation is always scheduled as a microtask rather than continuing inline. That's by design, and it keeps async functions behaviorally consistent regardless of whether the awaited value was ready immediately or not.

await Doesn't Make Things Run in Parallel

This is a common misunderstanding worth being explicit about.

const a = await fetch("/endpoint-a");
const b = await fetch("/endpoint-b");

These two requests don't run at the same time. The second fetch doesn't start until the first one resolves. You've written sequential async code, not parallel async code. If you want both requests to happen concurrently, you have to start both Promises before awaiting either:

const [a, b] = await Promise.all([fetch("/endpoint-a"), fetch("/endpoint-b")]);

await means "suspend this async function until this Promise settles." Whether things run in parallel depends entirely on when you start them, not on how many await keywords you use.

Where the Asynchronous Work Actually Happens

One more thing worth clarifying: when you await fetch("/data"), the HTTP request isn't happening inside JavaScript. The fetch call hands the request to the browser's networking layer, which handles it outside the JavaScript thread. JavaScript just registers interest in the result. When the response arrives, the browser resolves the Promise, and the event loop delivers the continuation back to your async function.

This is why await works without blocking the thread. The actual waiting isn't happening in JavaScript at all. It's happening in the host environment. JavaScript just picks up the result when it's ready.

async/await is a cleaner way to work with Promises. It makes the control flow easier to follow and the error handling more natural. But the execution model underneath it is the same: Promises, microtasks, and the event loop.

await doesn't pause JavaScript. It pauses the function you're currently inside, hands control back to the event loop, and lets the thread get on with other work until the Promise settles and your function is ready to continue.

The code looks like it stops and waits. The runtime doesn't.

What Is a System Call? And Why Does It Cost Time?

Aditya Sharma — Sat, 29 Aug 2026 07:32:22 +0000

Look at this line:

printf("Hello");

It looks like the simplest thing a program can do. One function, one string, one line. But between that call and the text appearing somewhere, a surprising amount happens. Your program doesn't just reach out and write characters to a screen. It can't. And understanding why is the interesting part.

Your Program Doesn't Own the Machine

When your code runs, it runs in what's called user space. The operating system kernel runs separately, with higher privileges. This separation isn't accidental. It exists because applications shouldn't be able to directly control hardware, read arbitrary memory belonging to other processes, or perform privileged operations. If any program could do any of that, the entire system would be one bug away from catastrophe.

So the kernel sits between applications and the resources they need. Want to write to a file? The kernel handles it. Want to send data over the network? The kernel handles it. Want to allocate memory beyond what you already have? The kernel handles it.

The mechanism through which a program asks the kernel to do something on its behalf is called a system call.

Your program
↓
User space
↓
System call
↓
Kernel
↓
OS-managed resource / hardware

printf() Is Not a System Call

This is where people often get confused. printf() is a C library function, not a system call. It lives in user space alongside your code. What it does is format the string, handle the conversion specifiers, and manage an output buffer. Eventually, when it actually needs to send data somewhere, the library calls write(), which is a system call.

printf()
↓
C library
↓
formatting + buffering
↓
write()
↓
system call
↓
kernel

That distinction matters. Library functions are just code. They run in user space with no special privileges. A system call is something different: it's a request that crosses the boundary between your program and the kernel.

What Actually Happens at the CPU Level

A system call isn't like a normal function call. When you call a regular function, execution stays in the same privilege level. The CPU jumps to another address in memory and comes back. Nothing about the system changes.

A system call triggers a hardware-supported mechanism that transfers execution from user-mode code to a kernel-controlled entry point at a higher privilege level. On x86-64, the instruction that does this is syscall. Other architectures have their own mechanisms. The point is that this transition is intentional and hardware-enforced, not just a jump in software.

The flow looks something like this:

User program
↓
Prepare syscall number + arguments
↓
CPU executes syscall instruction
↓
Kernel entry point
↓
Kernel validates the request
↓
Kernel performs the operation
↓
Return to user space
↓
Program continues

The kernel validates the request because it can't simply trust what the program says. If your program calls:

write(fd, buffer, length);

the kernel has to figure out what fd refers to, whether this process is allowed to use it, whether buffer points to memory the process actually owns, and what the real operation should be. This is part of the job. The kernel is the gatekeeper, not a passive executor.

Why This Costs Time

System calls aren't catastrophically slow, but they aren't free either. Crossing the user/kernel boundary has overhead that a normal function call doesn't.

Compare the two:

Normal function call:
user code → function → return

System call:
user code
↓
privilege transition
↓
kernel entry
↓
validation + kernel work
↓
return to user space
↓
program continues

The privilege transition itself takes time. The CPU has to switch modes, save state, verify the request, do the actual work, and then restore state to return to user space. Compared to jumping to a function in the same process, that's meaningfully more work.

One thing worth being clear about: a system call is not the same as a context switch. A context switch is when the operating system stops one process and runs another. A system call doesn't necessarily cause that. Your thread can make a system call, the kernel does its job, and your thread resumes. Context switches and system calls are related in some situations, but they're not the same thing.

Back to printf()

Here's where the buffering piece becomes practically useful.

Four calls to printf() don't necessarily mean four system calls. The C library can accumulate output in a user-space buffer and make one larger write() call instead of four small ones.

printf()
printf()
printf()
printf()
↓
user-space buffer
↓
single larger write
↓
one system call

This isn't just an implementation detail. It's a real design choice. If every printf() crossed into the kernel immediately, programs doing a lot of output would spend a surprising amount of time on privilege transitions. Buffering reduces that by batching work.

The same principle shows up in other places. Databases, network servers, and high-performance applications that do a lot of I/O often think carefully about how many times they cross the user/kernel boundary and how much work each crossing does. Not because system calls are to be avoided, but because doing thousands of tiny ones when you could do fewer larger ones adds up.

So when you write:

printf("Hello");

what you're actually setting in motion is closer to:

printf()
↓
C library formatting
↓
possibly buffered output
↓
write() system call
↓
kernel validates and executes
↓
OS-managed output resource

Your program doesn't directly control the machine. It describes what it wants, and the kernel decides how to make it happen. That request crosses a boundary that exists for good reasons, and crossing it has a cost.

That's why printf() is not free. And that's why it's worth knowing what's actually happening when you call it.

Why Is null More Than Just "No Value"? The Problem With null References.

Aditya Sharma — Fri, 28 Aug 2026 17:08:22 +0000

Look at this line:

let user = null;

There's something quietly strange about it. You have a variable. You have a value assigned to it. And that value is being used to express the idea that there is no value.

A missing value is being represented as a value. That contradiction is where the problem starts.

What a Reference Actually Is

In most languages, when you create an object, your variable doesn't hold the object directly. It holds a reference, something that points to where the object lives in memory.

variable
    ↓
  reference
    ↓
object in memory

This is why multiple variables can refer to the same object. They don't contain separate copies of the object; they hold references to the same underlying thing in memory.

When a variable is null, that reference points to nothing. The variable exists. The reference exists. But there's no object at the other end.

variable
    ↓
  null
    ↓
  (nothing)

What null actually is under the hood depends on the language and runtime. In many systems, a null reference is represented as a zero address or some other sentinel value, but that's an implementation detail. The important thing conceptually is that the reference isn't pointing anywhere meaningful.

Now do this:

user.name

If user is null, there's nothing to follow. The program tries to dereference a reference that leads nowhere. Depending on the language, this produces a null reference error, a null pointer exception, a crash, or some other runtime failure. The exact behaviour differs, but the cause is the same: you tried to use a reference that led nowhere.

Why Hoare Called It a Mistake

Tony Hoare introduced null references in ALGOL W in 1965. He's also the person who invented Quicksort, so he's not someone who made careless decisions. Decades later he called it his "billion-dollar mistake," characterising the enormous cumulative cost that null-related errors had caused across the software industry.

His reasoning wasn't that null itself is conceptually wrong. It was that introducing null adds an implicit state to every reference in the language.

Before null, a variable of type User means: there is a User here.

After null, a variable of type User means: there is a User here, or there isn't.

Every function that accepts a User now has two possible inputs instead of one. Every caller now has to decide whether to check. Every place that doesn't check is a latent bug. The type said User, but it was quietly lying.

How Null Propagates

The real cost isn't the crash. It's how far absence can travel before anyone notices.

Imagine a chain like this:

user.address.city.name

If address can be null, this line might fail. But the actual mistake might not be here. The mistake might be several layers back, in a database query that returned nothing, which got assigned to a variable typed as User, which got passed through two functions that didn't check, which eventually reached this line.

The crash happens here. The bug lives somewhere else entirely.

Once null is possible, that possibility has to be tracked everywhere the value travels. Functions that receive a nullable value have to handle absence. Functions that call those functions have to know. The chain looks something like this:

Function A → might return null
Function B → has to check
Function C → checks again
Function D → forgets

At scale, this becomes exhausting. Not because any single null check is hard, but because the information that a value might be absent has to stay accurate across every function, every layer, every developer who touches the code. The compiler isn't tracking it. Discipline is.

What Modern Languages Do Instead

Kotlin handles this by making nullability part of the type.

val name: String   // cannot be null
val name: String?  // might be null

A String and a String? are different types. If you try to call a method on a String? without handling the null case, the compiler complains. You can use the safe call operator:

name?.length

which returns null instead of crashing if name is null. Or you can do an explicit check. The point is that the type now communicates whether absence is possible, and the compiler helps enforce that you've dealt with it.

Rust goes further with Option<T>:

Option<String>

Rather than a null value, absence is represented explicitly through the type. A value is either Some(value) or None. There's no String that secretly might be nothing. If a function might not return a value, its return type says so explicitly. And if you want to use the value inside, you have to unwrap it, which means you have to handle the None case.

Some(value) → here's the value
None        → there is no value

This doesn't eliminate all bugs related to missing data. You can still write incorrect logic. But the possibility of absence is encoded in the type, not hidden behind a convention that everyone has to remember.

The deeper problem with null was never just that it causes crashes. It's that it introduces an implicit state that the type system doesn't track. A value that could secretly be nothing is a value the whole program has to silently handle everywhere.

When Hoare called it a billion-dollar mistake, he wasn't saying the concept of absence is wrong. Absence is real. Data can be missing. The question is whether that possibility should be invisible or explicit.

A missing value shouldn't pretend to be just another value. When it does, you don't have one kind of thing in your program. You have two. And only one of them is written in the types.

Why Is Composition Often Better Than Inheritance?

Aditya Sharma — Wed, 26 Aug 2026 04:53:42 +0000

Start with something simple. You're modelling birds.

class Bird:
    def fly(self):
        print("Flying")

class Eagle(Bird):
    pass

class Penguin(Bird):
    pass

Eagle looks fine. Penguin doesn't. A penguin is a bird, but it can't fly. So now what? You override fly in Penguin to do nothing, or raise an exception, or print "I can't fly." All of these feel wrong because they are wrong. You've given Penguin a method it shouldn't have, then tried to undo it.

This is a small example, but the problem gets worse as the application grows.

When the Hierarchy Starts Fighting You

Say the application now has Eagles, Penguins, Ducks, and Ostriches. Each has a different combination of capabilities:

Eagle: flies, walks
Penguin: walks, swims
Duck: flies, walks, swims
Ostrich: walks The natural instinct is to keep solving this with inheritance. Maybe you split Bird into FlyingBird and NonFlyingBird. But then Duck needs to swim, and Penguin needs to swim, and they're in different branches of the hierarchy. So you add a SwimmingBird. But Duck also flies. Now you're either duplicating behaviour or reaching for multiple inheritance, which opens its own set of problems.

The hierarchy is getting complicated not because the problem is complicated, but because you're trying to encode everything into a parent-child tree.

The deeper issue is that flying, walking, and swimming are independent capabilities. A bird might have any combination of them. Inheritance forces you to express that through a single chain of parent classes, and a chain can only go in one direction.

Why Inheritance Couples You to the Parent

Inheritance creates a strong relationship between a child class and its parent. The child gets everything the parent has, whether it needs it or not. If the parent changes, children are affected. If the parent grows to accommodate the needs of one subclass, it can start leaking behaviour that other subclasses don't need.

The problem isn't that inheritance is useless. It's that it bundles two separate ideas together: subtype polymorphism (a Penguin can be used wherever a Bird is expected) and behaviour reuse (a Penguin gets Bird's methods for free). When you only need one of these, inheritance can still make sense. But when the behaviour you're reusing doesn't fit cleanly, the coupling becomes a liability.

What If Behaviour Didn't Have to Come From the Parent?

Instead of inheriting capabilities, what if each bird was given the capabilities it actually needs?

class FlyingMovement:
    def move(self):
        print("Flying")

class WalkingMovement:
    def move(self):
        print("Walking")

class SwimmingMovement:
    def move(self):
        print("Swimming")

class Bird:
    def __init__(self, movement):
        self.movement = movement

    def move(self):
        self.movement.move()

Now:

eagle = Bird(FlyingMovement())
penguin = Bird(WalkingMovement())

Duck needs multiple capabilities, so you'd extend this slightly, but the key idea is already visible: the behaviour lives in a separate object that gets composed into the bird rather than inherited from a parent.

If you add a new bird tomorrow that can fly but not swim, you don't touch the existing hierarchy. You just compose it differently. The behaviour varies independently from the type.

Why This Makes Change Easier

The practical benefit shows up when requirements change.

With inheritance, adding a new capability often means modifying a parent class or restructuring the hierarchy. Either can affect classes you didn't intend to touch. Tests that were passing can start failing. The blast radius of a change is hard to predict.

With composition, you can change one behaviour object without affecting anything else. You can swap out a movement strategy without touching Bird. You can test FlyingMovement in complete isolation. If a new requirement means Penguins should now be able to glide short distances, you can introduce a GlidingMovement without reorganising the entire bird hierarchy.

Each piece of behaviour is a small, independent unit. You assemble what you need from those units rather than inheriting a bundle and spending effort removing what you don't need.

When Inheritance Still Makes Sense

None of this means inheritance is wrong.

Consider shapes:

class Shape:
    def area(self):
        pass

class Circle(Shape):
    def area(self):
        return 3.14 * self.radius ** 2

class Rectangle(Shape):
    def area(self):
        return self.width * self.height

Every Circle genuinely is a Shape. The subtype relationship is real and stable. Polymorphism is genuinely useful here: you can pass a Circle or a Rectangle wherever a Shape is expected, and the right area method gets called. The hierarchy isn't fighting the design, it's expressing it.

Inheritance works well when the subtype relationship is meaningful, the shared interface is stable, and the behaviour you're inheriting is actually the behaviour you need. When all of those are true, using it is reasonable.

The problem is when inheritance gets used as a mechanism for code reuse even when the subtype relationship isn't clean, because it's the first tool that comes to mind.

The Broader Lesson

Inheritance says: this object gets behaviour because it belongs to this hierarchy.

Composition says: this object gets behaviour because we gave it this component.

That distinction might seem subtle in a small example. In a large codebase with dozens of classes and six levels of inheritance, it becomes the difference between a design that accommodates change and one that resists it.

When you find yourself adding methods to a parent class to serve one specific child, or overriding methods just to disable inherited behaviour, or drawing an inheritance tree that keeps needing new branches, it's worth pausing.

What if the object didn't inherit this behaviour at all? What if it was composed from the pieces it actually needs?

That question, asked early enough, can save a lot of refactoring later.

DEV Community: Aditya Sharma

What Is a Man-in-the-Middle Attack? How Does TLS Stop It?

A Public Key Doesn't Come with Identity

What a Certificate Is

The TLS Handshake

Why Symmetric Encryption Handles the Data

Why the MITM Now Fails

What TLS Doesn't Cover

What Is IDOR? How Can Changing an ID Expose Someone Else's Data?

Authentication Is Not Authorization

What "Direct Object Reference" Actually Means

The Bug Often Lives in the Query

Unpredictability Is Not Authorization

Read Operations Are Not the Only Risk

Client-Side Controls Don't Count

Building Authorization That Holds

How Can Google Maps Find the Shortest Route So Fast?

The Graph Underneath

Dijkstra's Algorithm

A* Guides the Search

Bidirectional Search

Contraction Hierarchies

Why This Changes the Query

Preprocessing vs Query Time

What Is a Digital Signature? How Can You Prove a Message Wasn't Changed?

Why Hashing Alone Isn't Enough

Signing a Message

How Verification Works

Integrity and Authenticity Are Separate Properties

This Is Not Encryption

Signature Algorithms in Practice

Knowing Whose Key to Trust

Private Key Security

What Is CSRF? How a Website Can Make Your Browser Send a Request

Why the Browser Does This

Authentication Is Not the Same as Intent

CSRF Tokens

SameSite Cookies

Origin and Referer Headers

CSRF and XSS Are Different Threats

Bearer Tokens and the CSRF Threat Model

What Is SQL Injection? How User Input Can Become a Database Command

When Strings Become SQL

The Real Fix: Parameterized Queries

Prepared Statements

ORMs and Query Builders

Why Validation Isn't Enough

The Boundary That Has to Hold

What Is Cross-Site Scripting (XSS)? Understanding a Critical Web Security Vulnerability.

The Core Problem

Three Forms of XSS

Why innerHTML Matters

Frameworks and Where XSS Still Appears

Defenses

Stack vs Heap Memory: What Actually Happens When You Create a Variable?

The Stack

The Heap

Why Both Exist

Common Misconceptions

What Does `async/await` Actually Do in JavaScript?

An async Function Is Just a Function That Returns a Promise

What await Actually Does

The Thread Isn't Paused. The Function Is.

await Doesn't Make Things Run in Parallel

Where the Asynchronous Work Actually Happens

What Is a System Call? And Why Does It Cost Time?

Your Program Doesn't Own the Machine

printf() Is Not a System Call

What Actually Happens at the CPU Level

Why This Costs Time

Back to printf()

Why Is null More Than Just "No Value"? The Problem With null References.

What a Reference Actually Is

Why Hoare Called It a Mistake

How Null Propagates

What Modern Languages Do Instead

Why Is Composition Often Better Than Inheritance?

When the Hierarchy Starts Fighting You

Why Inheritance Couples You to the Parent

What If Behaviour Didn't Have to Come From the Parent?

Why `innerHTML` Matters

What `await` Actually Does