Your Database Will Be Breached Someday. The Question Is: Will Passwords Be Inside?

Keyur Gohil — Thu, 25 Jun 2026 06:41:27 +0000

Most developers think password hashing is about authentication.

It's not. Authentication is just a side effect. Password hashing exists for a much darker reason: because databases get stolen.

Every year, companies invest millions in firewalls, monitoring systems, cloud security, and access controls. Yet breach after breach continues to make headlines.

The uncomfortable truth is that security teams don't assume a breach will never happen.

They assume it eventually will. And when that day comes, one question determines whether the incident becomes a minor security event or a full-scale disaster:
Did you hash the passwords?

The Difference Between an Incident and a Catastrophe

Imagine an attacker gains read access to your production database. Not a far-fetched scenario.

A leaked backup.
A vulnerable API.
A compromised employee account.
A misconfigured cloud bucket.

The attacker runs a simple query:

SELECT email, password FROM users;

If your system stores passwords in plain text, the breach is over. The attacker already won.

No advanced techniques.
No brute force.
No expensive infrastructure.

They now possess something more valuable than your database itself: your users' digital identities.

Because users rarely reuse databases. They reuse passwords.

The same password protecting an account on your platform might also unlock their Gmail, GitHub, LinkedIn, banking app, or company VPN.

What started as your security problem instantly becomes everyone else's.

This Is Not Theoretical

History has repeatedly shown what happens when passwords are handled incorrectly. The RockYou breach exposed more than 30 million passwords stored in plain text. Attackers didn't need to crack anything. They simply read the data.

Years later, those leaked passwords were still appearing in credential stuffing attacks across the internet. A single backend decision survived longer than the company itself. That's the thing about password leaks. They don't expire when the incident report is published.

Why Hashing Changes Everything

A properly hashed password transforms a breach.

Instead of seeing:

john@example.com | John@123

an attacker sees:

john@example.com | $argon2id$v=19$m=65536...

The database is still stolen. But the passwords are not. Now every account becomes a separate cryptographic challenge.

Instead of instantly logging in, attackers must spend time, compute power, and money attempting to recover passwords. Many never become worth the effort.

Hashing doesn't prevent breaches. It limits the blast radius. And that's exactly why security professionals consider it non-negotiable.

The Mistake Many Developers Still Make

Some developers understand hashing but choose fast algorithms like SHA-256. Technically hashed. Practically vulnerable. Modern hardware can calculate billions of SHA-256 hashes every second. For password storage, speed is the enemy.

You want attackers to suffer. That's why algorithms such as Argon2id, bcrypt, and scrypt were created. Their purpose isn't efficiency.

Their purpose is making password cracking painfully expensive.

The Real Job of a Backend Engineer

A good backend engineer doesn't design systems assuming everything goes right. They design systems assuming something eventually goes wrong.

Servers get compromised.
Credentials leak.
Backups get exposed.

Humans make mistakes. The goal isn't building an unbreakable system.
The goal is ensuring that when failure happens, users aren't the ones paying the price.

Password hashing is one of the simplest ways to achieve that. A few lines of code today can prevent millions of credentials from becoming tomorrow's breach headline.

And that's why password hashing isn't a feature. It's a responsibility.

Adding Custom Headers in Axios: A Simple Guide

Keyur Gohil — Wed, 24 Jun 2026 11:47:05 +0000

When working with APIs, you'll often need to send additional information along with your requests. This information is usually passed through HTTP headers for authentication, tracking, content negotiation, and more.

In this article, we'll learn how to send custom headers using Axios.

Understanding Axios Request Syntax

Axios methods generally follow this pattern:

axios.method(url, data, options);

Where:

url → API endpoint
data → Request payload (for POST, PUT, PATCH, etc.)
options → Configuration object containing headers and other settings

For GET requests, there is no request body:

axios.get(url, options);
Adding Custom Headers

Custom headers are passed inside the headers property of the configuration object.

GET Request Example

axios.get('https://api.example.com/users', {
  headers: {
    'custom-header-key': 'your value'
  }
});

POST Request Example

axios.post(
  'https://api.example.com/users',
  {
    name: 'John Doe'
  },
  {
    headers: {
      'custom-header-key': 'your value'
    }
  }
);

Multiple Custom Headers

You can send multiple headers in the same request.

axios.get('https://api.example.com/users', {
  headers: {
    'Authorization': 'Bearer your-token',
    'X-App-Version': '1.0.0',
    'custom-header-key': 'your value'
  }
});

Using Variables for Headers

In real-world applications, header values are often dynamic.

const token = localStorage.getItem('token');

axios.get('https://api.example.com/profile', {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

Creating Reusable Axios Instances

If you use the same headers across multiple requests, create an Axios instance.

import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.example.com',
  headers: {
    'custom-header-key': 'your value'
  }
});

api.get('/users');
api.post('/posts', {
  title: 'Hello World'
});

Complete Example

import axios from 'axios';

axios.post(
  'https://api.example.com/login',
  {
    email: 'user@example.com',
    password: 'password123'
  },
  {
    headers: {
      'custom-header-key': 'your value',
      'Content-Type': 'application/json'
    }
  }
)
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});

Key Takeaways

Custom headers are added inside the headers object.
For GET requests, pass headers as the second argument.
For POST, PUT, and PATCH requests, headers are passed in the third argument.
Use Axios instances to avoid repeating common headers.
Headers are commonly used for authentication, API keys, and request metadata.

That's all! Adding custom headers in Axios is straightforward and helps you communicate additional information with your API requests efficiently.

DEV Community: Keyur Gohil