DEV Community: Rishu

If you're using Render's free tier and your backend keeps sleeping, this simple workaround has kept my Flask API alive without paying for upgrades. Hope it saves someone a few hours.

Rishu — Thu, 30 Jul 2026 07:27:56 +0000

Rishu

Jul 5

Stop Your Render Backend From Sleeping Every 15 Minutes (100% Free Fix)

#webdev #beginners #python #api

3 min read

Stop Letting AI Write Security Bugs: Introducing "hallint"

Rishu — Tue, 21 Jul 2026 08:40:47 +0000

If you're using Copilot, Cursor, or ChatGPT to ship code faster, you already know the upside. They save time, tackle boilerplate, and help you think through complex logic. But there's a blind spot nobody's tooling for yet: AI coding assistants generate the exact same class of security bugs, over and over again, with total confidence.

Traditional linters were designed for human-written code. They catch unused variables, missing semicolons, and common logic errors. They aren't built to catch the subtle, plausible-looking security holes that LLMs naturally default to.

That is why I built hallint. It is a free, open-source static analysis tool specifically tuned to catch the failure modes of AI code generation before they reach production.

The Problem AI Creates (That Most Linters Miss)

AI assistants fail differently than humans do. When you ask an LLM to generate an Express route or a database query, it takes the path of least resistance. It writes code that passes casual review, runs perfectly in local development, and creates real vulnerabilities in production.

Here are the most common AI failure patterns:

1. Hardcoded Secrets

AI will happily spit out const API_KEY = "sk-abc123...". It passes linting. It works locally. Pushing it to a public repo is a disaster.

2. SQL Injection by Default

AI loves template literals. db.query("SELECT * FROM users WHERE id = ${req.params.id}") looks completely fine at a glance, but it is a textbook SQL injection vector.

3. Missing Authentication

Generating CRUD routes is easy. Remembering to apply auth middleware to every single one of them? AI forgets constantly.

4. Auth Masking

This is the most dangerous one. When asked to add error handling to auth middleware, an LLM will often generate a try/catch that catches a token error but still calls next(), silently allowing unauthenticated requests through:

// AI generates this — looks like error handling, is actually a security hole
try {
  await verifyToken(req.headers.authorization)
} catch (e) {
  // token verification failed — but we call next() anyway
  next()
}

If verifyToken throws — expired token, invalid signature, missing header — the catch runs and the request proceeds as authenticated. The code looks intentional. It passes review. It is a direct authentication bypass.

The safe version:

try {
  await verifyToken(req.headers.authorization)
} catch (e) {
  return res.status(401).json({ error: 'Unauthorized' })
}

5. Permissive CORS

Setting cors({ origin: '*' }) is the AI's favourite one-liner to "fix" your CORS errors in development. It ships to production constantly.

What is `hallint`?

hallint is a TypeScript library and CLI tool that scans your JavaScript, TypeScript, and Python codebases for these specific AI-generated security and quality issues.

Instead of trying to be a general-purpose linter, it uses two detection layers to target AI-specific patterns:

Regex pattern matching — a fast first pass for known bad patterns
AST-style analysis — structural checks that understand multi-line logic, not just single-line text

The Rules Engine

hallint currently ships with 11 targeted rules:

Rule	Severity	What it catches
`hardcoded-secret`	Critical	API keys, tokens, and known prefixes (`ghp_`, `sk-`, `AKIA`, `xoxb-`)
`sql-injection`	Critical	User input directly interpolated into SQL queries
`unsafe-eval`	Critical	`eval()` or `new Function()` using dynamic input
`auth-masking`	Critical	Catch blocks that swallow auth errors, making failures silently pass
`missing-auth-check`	High	Route handlers missing authentication middleware
`xss-innerHTML`	High	Unsanitized strings assigned directly to `.innerHTML`
`permissive-cors`	High	`cors({ origin: '*' })` left in route handlers
`jwt-in-localstorage`	High	JWTs or auth tokens stored in `localStorage`
`swallowed-error`	High	Empty or comment-only catch blocks
`http-not-https`	Medium	Hardcoded `http://` URLs in fetch/axios requests
`async-no-catch`	Medium	`async` functions with no error handling (`--rules all` only)

How to Use `hallint`

Running via CLI

You don't even need to install it to try it out. Just point it at your source directory:

npx @asyncinnovator/hallint-cli ./src

Example output:

hallint scanning ./src...

src/routes/users.ts
  users.ts:4  CRITICAL  [hardcoded-secret]
  Hardcoded secret detected — API key, token, or password in source code
  > const apiKey = "sk-abc123def456ghi789jkl"
  fix: Move to environment variables: process.env.YOUR_SECRET_NAME

  users.ts:9  CRITICAL  [sql-injection]
  Possible SQL injection — user input directly concatenated into a query string
  > const result = await db.query(`SELECT * FROM users WHERE name = ${req.query.name}`)
  fix: Use parameterized queries: db.query('SELECT * FROM users WHERE name = $1', [req.query.name])

  users.ts:14  CRITICAL  [auth-masking]
  Catch block swallows an auth/token error — failed authentication may silently pass
  > } catch (e) {
  fix: Rethrow or respond with 401: catch (e) { return res.status(401).json({ error: 'Unauthorized' }) }

Summary: 3 issue(s) in 1 file(s) — 14ms
  3 critical

Only show what matters:

# Critical and high only
npx @asyncinnovator/hallint-cli ./src --min-severity high

# All rules including noisier heuristics
npx @asyncinnovator/hallint-cli ./src --rules all

# CI-friendly, no color
npx @asyncinnovator/hallint-cli ./src --no-color

Exit codes: 0 = clean, 1 = critical/high findings, 2 = unexpected error.

Using it as a Library

If you are building testing pipelines, pre-commit hooks, or editor plugins, import the core library directly:

npm install @asyncinnovator/hallint

import { scan, scanSource } from '@asyncinnovator/hallint'

// Scan your file system
const result = await scan({
  files: ['./src/**/*.ts'],
  rules: 'recommended',
  minSeverity: 'high',
})

result.findings.forEach(f => {
  console.log(`[${f.severity}] ${f.ruleId} at ${f.filePath}:${f.line}`)
  console.log(`  ${f.message}`)
})

// Or scan a raw string — useful in tests or editor integrations
const findings = scanSource(
  `const key = "sk-abc123abc123abc123abc"`,
  'virtual.ts'
)

Drop it into CI in 2 minutes

hallint exits 1 on any critical or high finding, making it a natural PR gate:

# .github/workflows/hallint.yml
name: hallint
on: [push, pull_request]

jobs:
  hallint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npx @asyncinnovator/hallint-cli ./src --min-severity high

Dive Deeper: Read the Full Docs on GitHub

The full documentation covers CI/CD integration, inline suppression (// hallint-disable), public route allowlists to reduce noise on intentional public endpoints, writing your own custom rules in under 30 lines, and the opt-in LLM explanation layer that attaches plain-English notes to each finding.

👉 Read the full documentation on GitHub

Get Started

AI is changing how we write code, but the security mistakes it makes are consistent and enumerable. hallint is MIT licensed, community-driven, and built to be extended. If you've seen an AI-specific vulnerability pattern that isn't covered yet, pull requests are open.

⭐ GitHub: github.com/Asyncinnovator/hallint
📦 Core library: @asyncinnovator/hallint
📦 CLI: @asyncinnovator/hallint-cli

We Pulled a Rule From Our AI Linter — Here's Why It Made the Tool Better

Rishu — Tue, 14 Jul 2026 11:36:38 +0000

Follow-up to I Built a Linter That Catches the Security Bugs AI Assistants Keep Writing. The comments on that post shaped most of what's in this update.

After the first post went up, I got a comment that stuck with me. Nazar Boyko wrote:

"Seven of your eight rules are 'this is a vulnerability.' async-no-catch is the odd one out... The first time someone runs hallint on a real codebase and gets forty of those next to one genuine hardcoded key, the signal you worked for is gone."

He was right. And fixing it taught me something about what makes a security linter trustworthy.

The Signal Problem

The whole point of hallint is to give you a reliable signal: this line is wrong. That's what makes it useful as a CI gate. When a finding fires, a developer — or an AI agent — should be able to look at the flagged line and agree without needing more context.

async-no-catch broke that bar. Plenty of correct async code has no try/catch because:

The caller handles the rejection
An Express error middleware catches it upstream
Throwing is the intended behavior Medium severity didn't save it. The moment you get forty async-no-catch warnings alongside one genuine hardcoded API key, you stop trusting the output. You turn the rule off. And now you've lost the one thing a security linter has to protect: the cost of ignoring a finding is zero.

The fix: async-no-catch is now removed from recommended. It still exists — --rules all opts you in — but it no longer ships alongside the seven security rules by default. recommended stays clean and gateable.

This is the difference between a linter that's interesting and one that's actually wired into CI.

The False Positive Problem on `missing-auth-check`

Dipankar Sarkar and Adam Lewis both flagged the same issue independently: health checks, webhooks, and public endpoints are supposed to have no auth middleware. Flagging them is noise. And noise gets rules disabled.

The fix needed to be explicit, not inferred. hallint now recognizes three inline suppression markers:

// public
app.get('/health', (req, res) => res.json({ status: 'ok' }))

// hallint-public
router.get('/metrics', (req, res) => res.json(metrics))

router.post('/webhook', /* hallint-public */ async (req, res) => {
  res.sendStatus(204)
})

Any of these tells hallint the route is intentionally public and skips the auth check. The marker can go on the line above or inline on the same line. No config file needed.

Other Fixes Shipped Since v0.1.0

hardcoded-secret — dual-pass detection

The original regex caught assignment-style secrets (api_key = "abc123"). It missed token prefixes that are dead giveaways regardless of variable name. The rule now runs a second pass targeting known provider-issued formats: ghp_, ghs_, sk-, AKIA, xoxb-, xoxp-, AIza, ya29.. A line containing any of these is flagged as critical even if the variable name looks innocent. Comment lines and process.env. reads are excluded.

sql-injection — honest message copy

The original message claimed "user input flowing into query." The detection was pattern-based — it couldn't actually prove data flow, just that a template literal appeared inside a query call. The message now says what the rule actually detects: template literal interpolation in a query string. Accurate scope, no false confidence.

Scanner dispatch — behavior now follows code, not metadata

Previously the scanner used rule.layer to decide whether to run regex or match(). A rule with layer: "ast" but no match() function would be silently skipped. Now rule.match() presence is the dispatch signal — if a rule defines match() it gets AST treatment, otherwise regex. layer is metadata only. Rule authoring is now harder to break.

async-no-catch brace counting — stripStrings() heuristic

Before being moved out of recommended, the rule's brace counter was made more robust. Template literals and inline strings were throwing off the depth counter, causing false positives. A stripStrings() pass now removes string content before counting { / }, significantly reducing noise.

Current Versions

Package	Version
`@asyncinnovator/hallint`	v0.1.8
`@asyncinnovator/hallint-cli`	v0.1.7

Install:

npm install @asyncinnovator/hallint

Or run without installing:

npx @asyncinnovator/hallint-cli ./src

CI Integration

hallint exits 1 on critical or high findings. Drop it into GitHub Actions in four lines:

- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with:
    node-version: 20
- run: npx @asyncinnovator/hallint-cli ./src

This blocks merges on real findings. The LLM layer — when it ships — will never contribute to exit code 1. Non-determinism doesn't belong in a CI gate.

What's Coming in v0.2

Cross-file router composition tracking

Right now missing-auth-check is same-file only. Middleware registered in app.ts isn't connected to routes defined in routes/users.ts. This is the honest limitation of regex analysis — you can't follow imports. v0.2 introduces tree-sitter, which makes cross-file tracking possible. This is the main structural change.

LLM layer — opt-in only

The optional LLM review pass ships in v0.2 as a strict opt-in (--llm ollama or --llm anthropic). It surfaces semantic issues and context-blind patterns the regex and AST layers miss, but those findings go in a separate output section and never block a merge.

New rules under consideration for v0.2–v0.3

silent-error-swallow — bare catch blocks that swallow errors without logging or rethrowing. Looks handled. Isn't.
jwt-in-localstorage — storing tokens where XSS can reach them.
hallucinated-dependency — imports of packages that don't exist in package.json (a genuine AI-specific failure mode)

Contributing

Each rule is a single file, ~30 lines, with a bad.ts and good.ts fixture. If you've seen a pattern AI assistants keep producing that hallint doesn't catch, the path from "I noticed this" to "I shipped a fix" is short. Issues labeled good first issue are pre-scoped and ready.

GitHub: github.com/Asyncinnovator/hallint

npm: @asyncinnovator/hallint · @asyncinnovator/hallint-cli

MIT licensed. Free for personal and commercial use.

I Built a Linter That Catches the Security Bugs AI Assistants Keep Writing

Rishu — Fri, 10 Jul 2026 07:11:18 +0000

I've been writing code with AI assistants for a while now. Copilot, Claude, ChatGPT — I've used them all. And for the most part, they're genuinely impressive. They save time. They help me think through problems. They write boilerplate I'd rather not write myself.

But here's the thing nobody talks about enough: AI-generated code has a specific category of bugs that normal linters don't catch.

Not syntax errors. Not style violations. I'm talking about security vulnerabilities, false-confidence patterns, and subtle logic issues that look completely correct — until they're not.

I got burned enough times that I built something about it. It's called hallint, and it's a free, open-source static analysis tool designed specifically for AI-generated code. You can find it on GitHub: github.com/Asyncinnovator/hallint

The Problem With AI Code (That ESLint Won't Help You With)

Traditional linters were designed for human-written code. They're great at catching things humans commonly get wrong — unused variables, missing semicolons, incorrect type usage.

But AI assistants fail differently.

Here are the patterns I kept seeing over and over:

1. Hardcoded secrets

AI assistants will happily write const API_KEY = "sk-abc123..." in your source code. It passes every lint check. It works perfectly in dev. And then you push to GitHub and your key is live in a public repo.

2. SQL injection

// AI generates this and it looks totally fine
const user = await db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)

No ESLint rule will flag this. But it's a textbook SQL injection vector. Every time.

3. Missing auth on route handlers

AI is great at generating CRUD routes. It's not great at remembering to add authentication middleware. You end up with a perfectly structured Express router where half the routes are completely unprotected.

4. Permissive CORS

app.use(cors({ origin: '*' }))

This is a one-liner fix for the CORS errors you see in development. AI assistants suggest it constantly. It's also a wildly bad idea in production.

5. innerHTML with unsanitized strings

element.innerHTML = userInput // XSS waiting to happen

LLMs write this pattern a lot. It's the obvious, readable way to set content — and it's a cross-site scripting vulnerability.

What I Built

hallint is a TypeScript library and CLI tool that scans your codebase for these AI-specific failure patterns.

It uses three detection layers:

Regex pattern matching — fast first pass for known bad patterns
AST analysis — structural checks that understand code, not just text
LLM review (optional) — uses Ollama or another provider to do deeper semantic analysis The idea is simple: it's a linter that knows what AI gets wrong, not just what humans get wrong.

Getting started

No install needed — just run it with npx:

npx @asyncinnovator/hallint-cli ./src

Or scan a specific glob pattern:

npx @asyncinnovator/hallint-cli "./src/**/*.ts"

Only care about serious issues? Filter by severity:

npx @asyncinnovator/hallint-cli ./src --min-severity high

It exits with code 1 on any critical or high finding, which makes it easy to use as a CI gate.

Use it as a library

If you want to integrate it into your own tooling:

npm install @asyncinnovator/hallint

import { scan } from '@asyncinnovator/hallint'

const result = await scan({
  files: ['./src/**/*.ts'],
  rules: 'recommended',
  minSeverity: 'high',
})

result.findings.forEach(f => {
  console.log(`[${f.severity}] ${f.ruleId} ${f.filePath}:${f.line}`)
  console.log(`  ${f.message}`)
  console.log(`  fix: ${f.fix}`)
})

You can also scan a string directly without touching the filesystem:

import { scanSource } from '@asyncinnovator/hallint'

const findings = scanSource(`const apiKey = "sk-abc123def456"`, 'example.ts')

The Rules Shipping

Right now hallint ships with eight rules, all targeting the patterns I described above:

Rule	Severity	What it catches
`hardcoded-secret`	critical	API keys, tokens, passwords in source code
`sql-injection`	critical	User input interpolated into SQL queries
`unsafe-eval`	critical	`eval()` or `new Function()` with dynamic input
`missing-auth-check`	high	Route handlers with no auth middleware
`xss-innerHTML`	high	Unsanitized strings assigned to `innerHTML`
`permissive-cors`	high	`cors({ origin: '*' })` in route handlers
`async-no-catch`	medium	`async` functions with no `try/catch` or `.catch()`
`http-not-https`	medium	Hardcoded `http://` URLs in fetch or axios calls

How It's Different From Running a Regular Linter

ESLint with the right plugins will catch some of this. But there are a few important differences.

Existing linters weren't built with AI failure modes in mind. They weren't designed around the question "what does an AI assistant get wrong?" They were designed around the question "what do humans get wrong?" Those are different questions with different answers.

hallint is designed to be AI-aware. The rules target the specific intersection of "AI generates this confidently" and "this is actually a problem." The goal isn't to be comprehensive — it's to be precise about the failure modes that matter most for AI-generated code.

The LLM layer is something ESLint can't do. When you enable the optional LLM review, hallint can flag issues that don't match a known regex or AST pattern — things like "this auth flow looks structurally correct but has a logical flaw." That's a different category of analysis entirely.

A Real Example

Here's the kind of thing it catches. Say you take some AI-generated Express code:

import express from 'express'
import db from './db'

const app = express()

app.get('/users/:id', async (req, res) => {
  const user = await db.query(
    `SELECT * FROM users WHERE id = ${req.params.id}`
  )
  res.json(user)
})

hallint flags it:

[critical] sql-injection: User input interpolated directly into SQL query.
  Use parameterized queries: db.query('SELECT * FROM users WHERE id = $1', [req.params.id])
  → src/routes/users.ts:6

Clean, direct, tells you exactly what to fix.

Drop It Into CI in 5 Lines

One of the things I wanted from day one was a zero-friction GitHub Actions integration. hallint exits with code 1 on critical or high findings, so this just works:

- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with:
    node-version: 20
- run: npx @asyncinnovator/hallint-cli ./src --min-severity high

You can also add it as a pre-commit hook via husky if you want to catch issues before they even get pushed.

It's Open Source — Contributions Welcome

The whole thing is MIT licensed and lives at github.com/Asyncinnovator/hallint. Issues and PRs are open.

I think this kind of tooling should exist in public, not behind a paywall. If AI-generated code has specific vulnerability patterns, the entire ecosystem benefits from shared, community-maintained detection rules.

The rule-writing surface is intentionally small — each rule is a single file (~30 lines) with a bad.ts / good.ts fixture. If you've seen an AI-specific pattern that hallint doesn't catch yet, the path from "I noticed this" to "I shipped a fix" is genuinely short. Issues labeled good first issue are pre-scoped and ready to pick up.

hallint is MIT licensed. Free to use in personal and commercial projects.

npm: @asyncinnovator/hallint · @asyncinnovator/hallint-cli

Stop Your Render Backend From Sleeping Every 15 Minutes (100% Free Fix)

Rishu — Sun, 05 Jul 2026 08:39:51 +0000

I recently built a small Flask backend for a side project. I deployed it on Render’s free tier, got that shiny HTTPS URL, and felt that classic developer rush of seeing my code live.

Proud of my work, I sent the link to a friend for feedback.

His response? "Bro, it's not loading."

I clicked the link myself. It did load, but only after staring at a blank screen for nearly a full minute. If you've ever deployed a passion project, you know that a 60-second loading screen is an absolute conversion killer.

Here is exactly why that happened, and how I fixed it permanently without spending a single dime.

The Problem: Render’s Free Tier "Cold Start"

After some digging, I realized this wasn't a bug—it’s a feature of Render’s free tier.

To save server resources, Render automatically spins down your service if it receives zero traffic for 15 minutes. When a new request finally comes in, the server has to boot back up before it can process anything. This "cold start" can take anywhere from 30 to 60 seconds.

If I'm testing the API from my laptop, I know what's happening. But to a real user opening the link cold, the site just looks broken.

Since the project was in its early stages, I didn't want to shell out money for a paid hosting plan yet. But I also needed my app to be snappy. I needed a workaround.

My First Thought: GitHub Actions (And Why It Failed)

My immediate instinct was to write a quick GitHub Actions cron job. The logic was simple: ping the server with a curl request every 14 minutes. If the server keeps getting hit before the 15-minute timer runs out, it never falls asleep.

on:
  schedule:
    - cron: '*/14 * * * *'

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - run: curl https://green-spoon-backend.onrender.com/api/health

Then I did the math.

GitHub gives you 2,000 free Actions minutes per month. Pinging the server every 14 minutes equals roughly 103 runs per day—which comes out to over 3,000 runs per month. That completely blows past the free limit. I definitely didn't want a surprise bill for a side project, so I scrapped the idea.

The Ultimate Fix: UptimeRobot

The core concept was still solid: I needed a tool to automatically ping the server. I just needed one that did it for free.

Enter UptimeRobot.

UptimeRobot is a standard website monitoring service. You give it a URL, and it checks it periodically to ensure your site is online. The best part? Their free plan allows checks every 5 minutes—more than frequent enough to keep a Render instance wide awake.

Step 1: Create a Lightweight Endpoint

Before setting up the monitor, I didn't want to ping my root / route. Root routes often trigger heavier logic or database calls, which is a waste of resources.

Instead, I added a dead-simple /health endpoint to my Flask app:

@app.route('/health')
def health():
    return {"status": "ok"}, 200

There are no database queries and no heavy business logic here. It just returns a 200 OK status confirming the server is alive. (Pro tip: Having a health check endpoint is a standard best practice in backend engineering anyway!)

Step 2: Set Up the Ping

I went to UptimeRobot and made a free account.
I created a new HTTP monitor.
I pointed it to my new endpoint: https://green-spoon-backend.onrender.com/api/health
I set the check interval to 5 minutes.

It took me less than two minutes to set up, and my Flask server hasn't fallen asleep since.

Won't I Get Spammed with Emails?

This was my biggest worry. I didn't want an email hitting my inbox every 5 minutes saying, "Hey, your site is still up!"

Thankfully, that’s not how UptimeRobot works. The pings happen silently in the background. You only ever get an email if your server actually goes down, and another when it comes back online. You get the benefit of keeping your server awake, bundled with professional-grade uptime monitoring for free.

Have you run into the free-tier sleep issue before? If you have a different setup or a cool alternative tool you use to keep your side projects awake, drop it in the comments below!

What Is Steganography? How It Works, Types, and Why It Matters

Rishu — Fri, 03 Jul 2026 04:55:13 +0000

I stumbled across steganography while researching privacy tools. The concept immediately caught me — not just encrypting data, but hiding the fact that data exists at all.

Cryptography says "there's a secret here, but you can't read it."

Steganography says "there's nothing here."

That distinction matters more than it sounds.

What is Steganography?

Steganography is the practice of concealing information within an ordinary, non-secret file or message. The word comes from Greek — steganos (covered) + graphein (writing). Covered writing.

Unlike encryption, which protects the content of a message, steganography protects the existence of a message. The goal isn't to make data unreadable — it's to make it undetectable.

The two techniques are often combined. Hide the data with steganography, encrypt it too, and you've got a system where an attacker can't read the message and can't even prove a message exists.

A Brief History

Steganography is ancient. The Greeks shaved a slave's head, tattooed a message on the scalp, waited for the hair to grow back, and sent the messenger on his way. The recipient shaved the head again.

The Romans wrote between lines of text using invisible ink made from fruit juice or milk. Heat would reveal the message.

During World War II, German spies used microdots — shrinking entire pages of text to the size of a period, hiding them in ordinary letters. The FBI called it "the enemy's masterpiece of espionage."

Digital steganography follows the same principle. Different medium, same idea.

How Digital Steganography Works

Digital files — images, audio, video — contain far more data than human perception can use. Our eyes and ears are lossy receivers. We can't detect small changes in color values, barely-audible frequency shifts, or tiny timing differences.

Steganography exploits that gap. It hides data in the parts of a file that humans can't perceive, while keeping the file looking (or sounding) completely normal.

Types of Steganography

1. Image Steganography

The most common form. Data is hidden in the pixel values of an image.

The standard technique is LSB (Least Significant Bit) steganography. Every pixel in an RGB image stores three values — red, green, blue — each as an 8-bit number between 0 and 255.

The last bit of each value contributes almost nothing to the final color. Changing it shifts the value by 1 out of 255 — imperceptible.

Original byte:  11001010  →  202
Modified byte:  11001011  →  203

By replacing the LSB of each byte across an entire image, you can embed a continuous stream of hidden data. A 1920×1080 PNG can carry ~777 KB this way, invisibly.

One important detail: this only works with lossless formats like PNG. JPEG's lossy compression discards small variations on every save — including your embedded bits. JPEG destroys LSB data.

2. Audio Steganography

Audio files work similarly. Sound is sampled thousands of times per second, each sample stored as a number. LSB modification of audio samples produces changes below the threshold of human hearing.

Another technique is phase coding — altering the phase of audio segments to encode data. Phase differences between segments are inaudible to humans but detectable by software.

3. Video Steganography

Video extends image steganography across frames. The sheer volume of data in a video file makes it an extremely high-capacity carrier. A short clip can hide gigabytes.

The challenge is that video is often re-encoded after recording, which can destroy embedded data — similar to the JPEG problem.

4. Text Steganography

Text has less redundancy than images or audio, but it's still possible. Techniques include:

Whitespace steganography — encoding bits using spaces and tabs at line endings
Unicode steganography — using visually identical Unicode characters that differ at the byte level
Line/word shifting — subtly adjusting spacing in printed documents

Text steganography is generally lower capacity and more fragile than image-based methods.

5. Network Steganography

Data can also be hidden in network traffic — in packet timing, unused header fields, or the ordering of packets. This is used in covert channel attacks and advanced persistent threats.

Steganalysis — The Other Side

Steganalysis is the detection of hidden data. If steganography is the attack, steganalysis is the defense.

The core idea: natural images have statistical properties. Pixel values aren't random — they follow patterns. LSB modification disrupts those patterns. Statistical analysis can flag images where the LSB distribution looks abnormal.

Tools like zsteg, StegExpose, and Stegdetect automate this. A chi-squared test on LSB distributions is often enough to detect naive implementations.

This is why encryption matters even in steganography. Even if steganalysis detects that something is hidden, strong encryption ensures the payload is still unreadable. Defense in depth.

Legitimate Uses

Steganography has a reputation problem — people assume it's only used for hiding illegal content. The reality is broader:

Digital watermarking — embedding invisible ownership metadata in images and audio
Journalistic source protection — passing documents inside ordinary images
Copyright protection — tracking unauthorized distribution of media
Covert communication — used historically by intelligence agencies and dissidents
Security research — understanding covert channels and detection methods

If you want to see LSB image steganography in practice, I built Stego.Image — a free, open-source browser tool that hides any file inside a PNG using DEFLATE compression + AES-256 encryption + LSB embedding. Everything runs client-side, nothing touches a server.

Source on GitHub. MIT licensed.

I Built an Image Steganography Tool — Hide Any File Inside a PNG with AES-256 Encryption

Rishu — Wed, 01 Jul 2026 08:06:52 +0000

I've been fascinated by steganography for a while — the idea that you can hide a file inside an image, and nobody would ever know it's there. Not just encrypted, but completely invisible.

So I built Stego.Image. A free, open-source tool that does exactly that — hide any file inside a PNG image, entirely in your browser.

What is steganography?

Steganography is hiding data inside another file so that the existence of the hidden data is concealed. It's different from encryption — encryption makes data unreadable, steganography makes data invisible.

The most common digital technique is LSB steganography — hiding bits of data in the least significant bits of image pixels. Changing the last bit of a pixel's color value shifts it by just 1 out of 255. Completely imperceptible to the human eye.

Original:  11001010  →  202
Modified:  11001011  →  203  ← you cannot see this difference

A 1920×1080 image has over 2 million pixels. At 3 bits per pixel across RGB channels, that's enough to hide ~777 KB of data — invisibly.

Why I built this

Most steganography tools I found were either desktop-only, outdated, or required uploading your file to a server. That last part kills the entire point — if your secret file touches someone else's server, it's not secret anymore.

I wanted something that:

runs entirely in the browser
uses proper modern encryption
works on any device, no install

So I built it.

How Stego.Image works

The pipeline has three stages:

1. Compress
The file is compressed using DEFLATE before anything else. Encrypted data is incompressible (it looks like random noise), so compression must happen first. This reduces payload size and increases how much you can hide.

2. Encrypt
Compressed data is encrypted with AES-256. The key is derived using PBKDF2-SHA256 at 100,000 iterations with a randomly generated salt — so your password never becomes the key directly. This makes brute-force attacks computationally expensive.

3. Embed
Encrypted bits are written into the LSBs of each RGB pixel channel using the HTML5 Canvas API. The output is saved as PNG — always PNG, because JPEG's lossy compression would destroy the embedded data on save.

Using it

Hide a file:

Upload a PNG carrier image
Upload the file you want to hide (any format — PDF, ZIP, image, document, anything)
Set a password
Download the output image

The output looks identical to the original. Nobody can tell the difference.

Extract a file:
Upload the stego image → enter the password → download your file.

That's it. No account, no install, no server. Try it at stego.image.

The security problem I fixed mid-build

The first version used crypto-js's default EvpKDF for key derivation — MD5-based, fast, and completely wrong for a security tool. It's the kind of thing that passes a quick test but fails the moment someone runs a brute-force attack.

I replaced it with PBKDF2-SHA256 at 100k iterations with a random salt. Files encoded with the old version are intentionally incompatible with the new one. Security over backward compatibility — no exceptions.

What you can use it for

Sending sensitive documents without revealing what's being transferred
Embedding invisible ownership metadata in images you distribute
Security research — understanding how LSB steganalysis works by building the thing it's trying to detect
Anywhere you need plausible deniability about a file's existence

Stack

React 19, Vite, crypto-js, pako, Bootstrap 5, deployed on Cloudflare Pages.

The entire thing is static — Cloudflare serves the build, your browser does all the work.

🌐 Live: https://stegoimage.pages.dev

🐙 GitHub: https://github.com/50RISHU/Stego.Image

MIT licensed. If you find a bug or want to contribute, PRs are open.

Image Steganography tool

Rishu — Sat, 20 Jun 2026 06:57:12 +0000

Rishu

Jun 7

Image Steganography Tool: Hide Any File Inside a PNG — AES-256 & Fully Client-Side

#showdev #javascript #opensource #security

2 min read

DEV Community: Rishu

If you're using Render's free tier and your backend keeps sleeping, this simple workaround has kept my Flask API alive without paying for upgrades. Hope it saves someone a few hours.

Stop Your Render Backend From Sleeping Every 15 Minutes (100% Free Fix)

Stop Letting AI Write Security Bugs: Introducing "hallint"

The Problem AI Creates (That Most Linters Miss)

What is hallint?

The Rules Engine

How to Use hallint

Running via CLI

Using it as a Library

Drop it into CI in 2 minutes

Dive Deeper: Read the Full Docs on GitHub

Get Started

We Pulled a Rule From Our AI Linter — Here's Why It Made the Tool Better

The Signal Problem

The False Positive Problem on missing-auth-check

Other Fixes Shipped Since v0.1.0

Current Versions

CI Integration

What's Coming in v0.2

Contributing

I Built a Linter That Catches the Security Bugs AI Assistants Keep Writing

The Problem With AI Code (That ESLint Won't Help You With)

What I Built

Getting started

Use it as a library

The Rules Shipping

How It's Different From Running a Regular Linter

A Real Example

Drop It Into CI in 5 Lines

It's Open Source — Contributions Welcome

Stop Your Render Backend From Sleeping Every 15 Minutes (100% Free Fix)

The Problem: Render’s Free Tier "Cold Start"

My First Thought: GitHub Actions (And Why It Failed)

The Ultimate Fix: UptimeRobot

Step 1: Create a Lightweight Endpoint

Step 2: Set Up the Ping

Won't I Get Spammed with Emails?

What Is Steganography? How It Works, Types, and Why It Matters

What is Steganography?

A Brief History

How Digital Steganography Works

Types of Steganography

1. Image Steganography

2. Audio Steganography

3. Video Steganography

4. Text Steganography

5. Network Steganography

Steganalysis — The Other Side

Legitimate Uses

I Built an Image Steganography Tool — Hide Any File Inside a PNG with AES-256 Encryption

What is steganography?

Why I built this

How Stego.Image works

Using it

The security problem I fixed mid-build

What you can use it for

Stack

Image Steganography tool

Image Steganography Tool: Hide Any File Inside a PNG — AES-256 & Fully Client-Side

What is `hallint`?

How to Use `hallint`

The False Positive Problem on `missing-auth-check`