DEV Community: Rishu

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

My Flask Backend Was Falling Asleep Every 15 Minutes — Here's How I Fixed It Completely Free

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

I built a small Flask backend for one of my side projects, deployed it on Render's free tier, and felt that usual satisfaction of seeing it live with an HTTPS URL and everything. Then I shared the link with a friend to get some feedback.

His reply: "bro it's not loading."

I opened it myself. It did load — but after sitting there for almost a minute on a blank screen. Not a great first impression.

What Was Actually Happening

After a bit of digging I found out this is just how Render's free tier works. If your service gets no traffic for 15 minutes, Render shuts it down to save resources. The moment a new request comes in, it has to boot the server back up before it can respond — and that cold start can take anywhere from 30 seconds to a full minute.

For me sitting at my laptop knowing what's happening, it's fine. For anyone else opening the link cold, it just looks like the site is down or broken.

I didn't want to pay for hosting yet — the project was still in early stages and didn't need production-level reliability. But I also didn't want every first impression to be a 60 second loading screen. So I started looking for a workaround.

First Thought: GitHub Actions

My first idea was to write a simple GitHub Actions workflow that runs every 14 minutes and sends a curl request to my server. If something keeps hitting it before the timer runs out, it never goes to sleep. Simple enough in theory.

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

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

But then I did the math. GitHub's free tier gives you 2,000 Actions minutes per month. Pinging every 14 minutes means roughly 103 runs per day, which comes out to around 3,000+ runs per month. That exceeds the free limit by a lot, and I didn't want surprise charges on a side project I wasn't even monetizing. Crossed that off the list.

What Actually Worked

The core idea was still the same — something needs to ping the server regularly so it never hits the 15 minute idle limit. I just needed a tool that could do it for free without consuming GitHub minutes.

I came across UptimeRobot. It's primarily a monitoring service — you give it a URL, it checks that URL every few minutes, and sends you an alert if it goes down. The free plan checks every 5 minutes, which is more than frequent enough to prevent Render from sleeping.

But before setting that up, I wanted a proper endpoint to ping — not just the root / which might have heavier logic attached. I added a dead simple /health route to my Flask app:

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

No database queries, no business logic, nothing that could fail. Just a response that says the server is alive. This is actually a good practice for any backend — having a health endpoint is useful beyond just keep-alive purposes, like when you want to confirm a deployment went through or check if a service is up during debugging.

Then I went to UptimeRobot, created a free account, and added a new HTTP monitor pointing to https://green-spoon-backend.onrender.com/api/health with a 5 minute check interval. Took about 2 minutes to set up.

That's genuinely it. The server has stayed awake ever since.

Something I Was Worried About

My first concern was that I'd get flooded with emails — a notification every 5 minutes saying "your site is up" would be unbearable.

But that's not how it works. UptimeRobot pings your URL silently in the background. You only get notified when something actually goes wrong — when the server goes down, and again when it comes back up. During normal operation you hear nothing at all. It's actually a nice bonus to have real uptime monitoring on top of the keep-alive behavior.

If you've dealt with this before and found a better way to handle it, drop it in the comments — always curious how others approach this.

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