DEV Community: siyadhkc

Why Most Django Boilerplates Are Insecure by Default

siyadhkc — Wed, 03 Jun 2026 16:18:06 +0000

You found a Django boilerplate on GitHub. It has 2k stars, a clean README, Docker support, and a Makefile. You clone it, rename a few things, push to production.

Congratulations. You just shipped someone else's security assumptions.

The Illusion of "Production-Ready"

Every boilerplate claims to be production-ready. The badge is right there in the README. But production-ready for what? A side project? A fintech API? A platform that stores user PII?

"Production-ready" in most boilerplates means: it runs without errors. That's it. The security part is usually left as a comment that says # TODO: change this before deploy — which, statistically, nobody changes.

This isn't an attack on boilerplate authors. They're solving a real problem: Django's initial setup is tedious, and abstracting that away has genuine value. The problem is that the defaults they choose get inherited silently by every project that forks them.

And defaults are everything in security.

What Actually Ships in Most Boilerplates

Let me walk through what you'll typically find if you dig past the README.

1. `DEBUG = True` Tied to an Environment Variable That Defaults to True

# settings.py
DEBUG = os.environ.get("DEBUG", "True") == "True"

This is the canonical mistake. The intent is good — make DEBUG configurable. But the default is True. So if you deploy and forget to set the environment variable, Django will cheerfully expose your full stack trace, local variables, installed apps, and settings to anyone who hits a 404.

I've seen this in repos with thousands of stars. The author probably never intended it to ship this way. But it does.

The fix is trivial:

DEBUG = os.environ.get("DEBUG", "False") == "True"

One word. The default should always be the safe option.

2. `SECRET_KEY` Hardcoded or Weakly Generated

SECRET_KEY = "django-insecure-abc123xyz-changeme"

Django's startproject actually warns you with the django-insecure- prefix now. But plenty of boilerplates generated before that convention still have static keys checked into version control.

Even the ones that generate it dynamically sometimes do it wrong:

# generates a NEW key on every restart
SECRET_KEY = os.environ.get("SECRET_KEY", get_random_secret_key())

This means every server restart invalidates all existing sessions and CSRF tokens. That's not a security fix — that's a different bug wearing a security costume.

The secret key needs to be generated once, stored as an environment variable, and never committed to Git. Full stop.

3. `ALLOWED_HOSTS = ["*"]`

ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "*").split(",")

Again — the default is the dangerous value. ALLOWED_HOSTS = ["*"] disables Django's Host header validation entirely, opening the door for host header injection attacks. This isn't theoretical. Attackers use it to poison password reset emails with their own domain.

The boilerplate author probably put "*" there so you can docker-compose up without configuring anything. Convenience for the developer. Risk for the user.

4. CORS Configured Wide Open

# django-cors-headers
CORS_ALLOW_ALL_ORIGINS = True

CORS exists to protect your users' browsers. When you set this to True, you're telling every origin on the internet that it can make credentialed requests to your API. Combined with SESSION_COOKIE_SAMESITE = None (which some boilerplates also set), you've recreated the conditions for CSRF attacks in a Single Page App context.

The reasoning is always the same: "I'll change this when I know my frontend's domain." But that moment never comes cleanly in the chaos of early development, and it ships.

5. No Security Headers

Django doesn't set security headers by default. You need django.middleware.security.SecurityMiddleware in MIDDLEWARE, and then you need to actually configure it:

SECURE_BROWSER_XSS_FILTER = True  # deprecated but harmless
SECURE_CONTENT_TYPE_NOSNIFF = True
X_FRAME_OPTIONS = "DENY"
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True
SECURE_SSL_REDIRECT = True

Most boilerplates have SecurityMiddleware in the list. Few have these settings configured. HSTS in particular is almost always missing — which means every user's first request is over HTTP until they get redirected.

6. Session and Cookie Settings Left at Defaults

# What most boilerplates ship
SESSION_COOKIE_HTTPONLY = True   # ✅ Django default, usually fine
SESSION_COOKIE_SECURE = False    # ❌ Default — cookies sent over HTTP
CSRF_COOKIE_SECURE = False       # ❌ Default — CSRF token sent over HTTP
SESSION_COOKIE_SAMESITE = "Lax"  # ✅ Usually fine, but often overridden

SESSION_COOKIE_SECURE = True means the browser will only send the session cookie over HTTPS. Leaving it False means someone on the same network can intercept it over HTTP. This is a solved problem — but it requires explicitly setting it, and boilerplates rarely do.

7. Django Admin Sitting on `/admin/`

urlpatterns = [
    path("admin/", admin.site.urls),
    ...
]

This is Django's own default, so I can't blame boilerplate authors entirely. But nobody changes it either. The admin panel at /admin/ is the first thing automated scanners probe. Moving it to something non-guessable costs you nothing and removes you from a significant percentage of automated attacks.

path("your-own-path-here/", admin.site.urls),

Why This Keeps Happening

The ecosystem isn't malicious. It's optimizing for the wrong metric.

Boilerplates get stars based on how quickly they get you from zero to running. Security settings that would break a local setup — like SECURE_SSL_REDIRECT = True without an SSL cert — get disabled so the DX is smooth. The secure version is the harder version to demo.

Django itself deserves some of this too. The framework ships with safe defaults in some areas (CSRF protection is on by default, passwords are hashed), but makes you opt-in to the rest. That opt-in surface is where boilerplates consistently fail to follow through.

And then there's us — developers who clone first, configure later, and ship before "later" arrives.

What a Secure Boilerplate Default Looks Like

Split your settings. This is non-negotiable.

settings/
    base.py      # shared across all environments
    local.py     # DEBUG=True, no SSL, relaxed CORS
    production.py  # strict everything

In production.py, the defaults should be secure. If something is missing — a SECRET_KEY, a DATABASE_URL — the app should refuse to start, not silently fall back to an insecure value.

# production.py
SECRET_KEY = os.environ["SECRET_KEY"]  # KeyError if missing — intentional
DEBUG = False
ALLOWED_HOSTS = os.environ["ALLOWED_HOSTS"].split(",")

SECURE_SSL_REDIRECT = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
CORS_ALLOWED_ORIGINS = os.environ["CORS_ALLOWED_ORIGINS"].split(",")

Notice the os.environ["KEY"] without .get(). If the variable isn't set, it raises a KeyError and the app doesn't start. That's correct behavior. Failing loudly in production is safer than running silently insecure.

A Checklist Before You Ship

If you're using any boilerplate — including one you wrote yourself six months ago — run through this before you deploy:

[ ] DEBUG = False in production, with no unsafe default fallback
[ ] SECRET_KEY sourced from environment, never in version control
[ ] ALLOWED_HOSTS explicitly set, no wildcards
[ ] CORS_ALLOW_ALL_ORIGINS = False, origins explicitly whitelisted
[ ] SESSION_COOKIE_SECURE = True
[ ] CSRF_COOKIE_SECURE = True
[ ] SECURE_SSL_REDIRECT = True
[ ] SECURE_HSTS_SECONDS set
[ ] Django admin URL is not /admin/
[ ] django.middleware.security.SecurityMiddleware is first in MIDDLEWARE

Run python manage.py check --deploy too. Django ships a deployment checker that will call out many of these issues. Most developers don't know it exists.

The Honest Takeaway

Boilerplates are a starting point, not a finished product. The problem is the word "boilerplate" implies it's something you don't need to think about — just add your code on top. But the security layer is exactly the part that requires thinking.

The ecosystem needs better defaults. Boilerplate authors should make the safe behavior the path of least resistance, not the other way around. Django could be more opinionated about production configuration. And we — as developers shipping things to real users — need to stop treating security settings as a post-launch concern.

It never becomes post-launch. It becomes a breach report.

If you found this useful, I write about Django security, API security, and backend architecture on Dev.to. The next piece will be on OWASP API Top 10 vulnerabilities in real Django REST Framework code — the ones that slip through code review.

I Built a Pre-Commit Secret Scanner Because GitHub's Is Too Late

siyadhkc — Sun, 24 May 2026 15:31:20 +0000

Let me start with a confession.

I have accidentally committed a .env file. Not to a private internal repo with no consequences. To a public GitHub repo. With a real Stripe test key in it.

I caught it within minutes, deleted the file, rotated the key, pushed a new commit. Classic developer scramble. Nothing happened — at least as far as I know.

But that "as far as I know" lived in my head for a while.

That experience is what eventually led me to build env-guard — a Python CLI tool that scans your project for secrets and installs as a git pre-commit hook, blocking the commit entirely if it finds something suspicious. The secret never leaves your machine. No scramble. No rotation. No anxiety.

The problem with GitHub Secret Scanning (it's a timing problem)

GitHub has a feature called Secret Scanning. It's legitimately good — it covers dozens of credential formats across major providers and will notify you when it finds something. I'm not here to trash it.

But it has one fundamental flaw that no amount of good engineering can fix:

It runs after you push.

Think about what that means. By the time GitHub scans your code and sends you an alert, your secret has already:

Left your machine
Traveled over the internet
Landed on GitHub's servers
Been indexed, if the repo is public

Automated bots scrape public GitHub repos constantly. We're talking seconds after a push, not minutes. GitHub will alert you, but the key is already out there. You're now rotating credentials, auditing API usage logs, and hoping whoever grabbed it hasn't done anything with it yet.

Without env-guard:
  code → commit → push → GitHub scans → alert → key already exposed ❌

With env-guard:
  code → commit blocked → fix locally → push clean code ✅

Think of GitHub Secret Scanning as your last line of defense. env-guard is your first.

The secret never enters git history at all. There's nothing to rotate, nothing to audit, and nothing to lose sleep over.

Who this is actually for

If you work with any of the following on a regular basis, env-guard is for you:

API keys — OpenAI, Stripe, Twilio, SendGrid, any SaaS you integrate with
Cloud credentials — AWS access keys, GCP service accounts, anything that costs money if misused
Database connection strings — postgres://, mongodb://, redis:// — all of these contain passwords
Private keys — RSA, EC, OpenSSH — the kind that give access to your servers

Basically: if you work on real software that talks to real services, you have secrets somewhere in your local environment. And humans make mistakes. Even careful ones.

I've seen this happen to senior engineers. It's not a skill issue. It's a missing safety net issue.

What it detects

env-guard ships with 54 detection rules covering every major category of credential you'd encounter in a typical backend or fullstack project:

Category	What it catches
AWS	Access Key ID, Secret Access Key, Session Token
Google	API Key, OAuth Client Secret, Service Account JSON
GitHub	Personal Access Token, OAuth Token, App Token
Stripe	Live and Test Secret Keys, Publishable Keys
OpenAI / Anthropic	API Keys
Slack	Bot Token, User Token, Webhook URL
Twilio	Account SID, Auth Token
SendGrid	API Key
Databases	PostgreSQL, MySQL, MongoDB, Redis connection strings
Private Keys	RSA, EC, PGP, OpenSSH private key blocks
Django	SECRET_KEY
Generic	Password assignments, token assignments, API key assignments
And more	Razorpay, NPM, PyPI, Heroku, Netlify, Cloudinary, and others

Each rule carries a severity level — HIGH, MEDIUM, or LOW — so you're not staring at an undifferentiated wall of warnings. A live Stripe secret key is HIGH. A generic-looking token assignment might be MEDIUM. The output is human-readable and actionable.

$ env-guard scan .

env-guard scan report
Path    : .
Scanned : 42 files
Found   : 1 potential secret(s)

  ✖ HIGH  Stripe Live Secret Key
  File : config/settings.py:12
  Code : STRIPE_KEY = "sk_live_abc123..."

──────────────────────────────────────────────────
  1 HIGH
──────────────────────────────────────────────────

Scan failed — secrets detected. Do not commit.

File. Line number. What was found. Severity. No ambiguity, no guesswork — you know exactly where to go and what to fix.

Getting started in 60 seconds

Install it:

pip install env-guard

Requires Python 3.8+. Run a scan on your current project right now:

env-guard scan .

Go ahead. Run it on a real project you're working on. You might be surprised what's sitting there.

The pre-commit hook — the part that actually changes your habits

Ad-hoc scanning is useful for audits, but the real shift happens when env-guard becomes invisible. When you don't have to think about running it. When it just works in the background every single time you commit.

That's what install-hook does:

env-guard install-hook

Run that once inside your repo. From that point forward, every git commit triggers an automatic scan before anything gets written to git history:

env-guard: scanning for secrets...
env-guard: commit blocked. Remove secrets before committing.
env-guard: to skip this check (NOT recommended): git commit --no-verify

If nothing is found, the commit proceeds normally — you won't even notice it ran. If something is found, the commit is hard-blocked with a clear message telling you exactly where the problem is.

The --no-verify escape hatch exists because I didn't want to be heavy-handed. Sometimes you're committing a test fixture that contains a fake-looking credential. The escape hatch is there — but it requires a conscious decision, and that friction is intentional.

To remove the hook if you ever need to:

env-guard uninstall-hook

Handling false positives

Every scanner has them. A SHA-256 hash that structurally resembles an API key. A documentation example with a placeholder that matches a pattern. A test fixture with a fake credential for unit tests.

env-guard handles this with a .envguardignore file in your project root — same concept as .gitignore, one pattern per line:

# Ignore specific files
tests/fixtures/sample.env

# Ignore by extension
*.log

# Ignore entire directories
docs/

Because it's a committed file, your whole team gets the same exclusions automatically. No per-developer configuration needed.

CLI flags for different workflows

A few flags that cover the common situations:

# Only surface the critical findings
env-guard scan . --severity HIGH

# Machine-readable output for scripting
env-guard scan . --format json

# Scan without failing the process (reporting mode)
env-guard scan . --no-fail

The --no-fail flag is worth calling out specifically. If you're adding env-guard to an existing large codebase, you probably don't want to immediately block everything and deal with 50 findings on day one. Run with --no-fail first, triage what's real vs. false positive, set up your .envguardignore, then remove the flag when you're confident. Gradual adoption is a completely valid path.

For teams: CI/CD as a second checkpoint

Pre-commit hooks protect your own machine. But what about:

External contributors who clone the repo and don't run install-hook
New team members who haven't set up their environment yet
Automated processes that generate config files with credentials

For that, env-guard works in CI pipelines too. Here's a GitHub Actions workflow you can drop into any repo:

name: Secret Scan

on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - run: pip install env-guard
      - run: env-guard scan .

This gives you the same local protection applied to every PR, from every contributor, on every push. env-guard locally + this workflow in CI = defense in depth that actually makes sense.

env-guard vs GitHub Secret Scanning — use both

	env-guard	GitHub Secret Scanning
When it runs	Before commit, on your machine	After push, on GitHub's servers
Blocks the secret	Yes — commit is blocked	No — secret is already pushed
Works offline	Yes	No
Custom ignore rules	Yes, `.envguardignore`	Limited
Free	Yes	Yes (public repos)
Requires GitHub	No	Yes

These aren't competing tools. They protect different parts of the pipeline. Run env-guard locally to stop secrets before they ever leave your machine. Keep GitHub Secret Scanning on as a fallback for anything that slips through — external contributors, edge cases, human error. Use both.

The thing I keep thinking about

There's a concept in security called "shift left" — the idea that you should catch problems as early in the development process as possible, because the earlier you catch something, the cheaper it is to fix and the less damage it causes.

A leaked credential caught before the commit? Zero cost. Rotate nothing. Tell no one. Move on.

A leaked credential caught after a push to a public repo? Rotate the key, audit usage logs, send an incident report if it's a team environment, and spend a few days with that low-grade anxiety of "did anything actually get accessed?"

env-guard is a shift-left tool. The entire design philosophy is: don't give the secret a chance to travel. Keep it local. Catch it at the source.

Try it

pip install env-guard
env-guard scan .

If you want the hook:

env-guard install-hook

Source on GitHub: github.com/siyadhkc/env-guard

If it catches something on the first scan — good. That's the point. And if you hit a false positive that's annoying, open an issue. I want the pattern library to be genuinely useful, not just technically comprehensive.

What's coming next

A few things on the roadmap:

Pre-push hook option — a second checkpoint right before the push, for teams who want both
More detection rules — 54 is solid but the ecosystem keeps growing
Project-level config file — custom severity thresholds, rule toggles, team-specific settings beyond just ignores

If this is useful to you, star the repo and watch for updates. And if you've ever had a bad day because of an exposed credential — you're not alone, and this is for you.

Built with Python. MIT licensed. Contributions welcome.

I built a multi-tenant food delivery platform alone. Here's what nobody tells you about that.

siyadhkc — Sun, 17 May 2026 16:40:10 +0000

Four user roles. One payment gateway that lied to me. Three rewrites of the same feature. And a GPS bug that nearly flooded my database. This is the real story behind Savor.

I was tired of building things that felt fake

At some point every developer hits a wall with tutorial projects. You've built the weather app. You've done the blog CRUD. You've cloned Twitter in a weekend. And none of it actually teaches you what it feels like when four different types of users are all touching the same data at the same time, and you have to keep their worlds completely separate.

I wanted something that would break me a little. Something with real business logic, real money, real state synchronization problems. Food delivery checked every single box.

Customers order food. Restaurants fulfill it. Delivery agents pick it up. Admins oversee everything. Four completely different actors, all interacting with overlapping data, all in real time. That's not a tutorial problem — that's a systems problem. I called it Savor.

"Building this was the first time I genuinely didn't know if something would work until I ran it. That was terrifying and that was the point."

These aren't exciting choices. They're correct ones.

Django REST Framework on the backend. React 19 + Vite on the frontend. PostgreSQL. I didn't pick these to be cool. I picked them because the problem needed a mature ORM, ACID-compliant transactions, and a frontend that wouldn't fight me on state management.

Layer	Tech	Why it mattered
Backend	Django 5.1 + DRF	Atomic transactions, battle-tested ORM, signals for cross-model side effects
Frontend	React 19 + Vite	Fast HMR, modern concurrent features
Auth	SimpleJWT + rotation	Silent 60-min access token rotation, 7-day refresh — no mid-session logouts
Database	PostgreSQL	ACID compliance. Nested financial data cannot partially save.
Payments	Razorpay	Localized processing, webhook verification
Media	Cloudinary CDN	Edge delivery. Serving images from Django would be career-ending performance-wise.
Styling	Tailwind CSS 4.0	Zero runtime. Design tokens kept four portals visually coherent.
Animations	Framer Motion	Micro-interactions. A premium feel isn't just design — it's movement.
Mapping	Leaflet.js	Live GPS plotting on the customer tracking view

The one decision I'd revisit: React Context API over Zustand. Context was fine for the scope but I started feeling prop drilling pain by week four. If you're building something this complex, just start with Zustand.

Each portal was its own distinct problem

The customer app was where I started because it's the most tangible — you can see it, click it, feel it. The discovery architecture has two layers: global cuisines (Arabian, South Indian, Desserts) and restaurant-internal categories (Must Try, Specials). Getting that hierarchy right in the serializers took four iterations. The cart was where I first hit real business logic — you can't add items from two different restaurants to the same cart. I built persistent local state that checks restaurant ID on every cart mutation. Sounds simple. It wasn't.

The restaurant partner portal was the one I underestimated the most. I assumed it'd be a dashboard with some CRUD. What I got was the most complex portal in the system. Restaurant owners are power users. The order lifecycle — Pending → Accept → Preparing → Ready for Delivery — cascades into downstream state changes across three other portals simultaneously. I used Django signals for this. Required very careful thinking about idempotency.

The delivery agent interface is the one I'm most proud of technically. Geo-fencing logic is implemented at the queryset manager level, not the view level. A Kochi agent cannot see a Mumbai dispatch — and this isn't a frontend filter someone can bypass with a crafted request. The data simply doesn't exist in the response. Getting the earnings calculation to be atomic and accurate on the Delivered status transition took three rewrites.

The admin console could have been an afterthought. I didn't let it be. With 3,000+ menu items seeded from the Kerala restaurant dataset, server-side pagination was non-negotiable. I implemented cursor-based pagination — offset pagination on PostgreSQL becomes unusably slow past 1,000 rows.

Live demo: food-delivery-seven-bice.vercel.app

The struggles nobody writes about in project writeups

01 — Multi-tenancy took three complete rewrites

The first version filtered at the serializer level. That works until a restaurant owner in tenant A briefly sees an order from tenant B during a race condition. The second version moved filters to the view layer — better, still bypassable. The third version put tenant scoping into the queryset manager. That's where it needed to be from the start. Two full days of debugging a bug that shouldn't have existed if I'd thought it through properly the first time.

02 — Razorpay webhook verification in development is a trap

Webhooks need a publicly accessible endpoint. In development, you don't have one. I spent a full day debugging a signature verification failure that turned out to be a timezone mismatch in how I was constructing the HMAC payload. I ended up building a local webhook simulator specifically for dev testing, stripped out before production. This is not in any Razorpay tutorial I found.

03 — GPS telemetry nearly destroyed my database

Early testing: delivery agents broadcast coordinates on every geolocation API event. The browser's watchPosition fires multiple times per second. At 10 concurrent test agents, that was hundreds of database writes per minute for a field that only needs to update every few seconds. I added a frontend debounce and a backend timestamp guard that rejects updates more frequent than 3 seconds. The database survived. My nerves less so.

04 — CSS across four portals with four different visual languages

The customer app is warm and premium. The delivery interface is utilitarian and fast. The admin console is dense and data-heavy. The partner portal is somewhere between all three. Tailwind's design token system helped, but by week three the tokens were drifting in ways that required a full audit to fix. CSS architecture is genuinely hard at scale and nobody talks about the multi-portal version of this problem.

05 — The cart constraint bug that appeared in production and nowhere else

Cart state was using localStorage with a restaurant ID key. In production, the Vercel edge occasionally delivered a cached app version mid-session with a stale cart key. The constraint check passed because the key comparison was against an old restaurant ID. Never reproduced locally. Fixed by adding a session-scoped cart version hash alongside the restaurant ID. The worst kind of bug: requires production traffic to surface.

The one decision that saved the whole system

Early on I had a choice: enforce multi-tenancy at the UI layer or the data layer. The UI layer is easier — you just filter what you show. The data layer is harder — you modify how querysets are constructed at the model level so filtered-out data is never even fetched.

I chose the data layer. Every restaurant-scoped query goes through a custom queryset manager that injects the tenant ID before the SQL hits PostgreSQL. Bypassing tenant isolation requires compromising the Django application layer itself — not just crafting a request with different parameters.

For financial data, I used @transaction.atomic everywhere that touched nested profile updates. A restaurant's payout configuration and platform commission rate update in a single atomic operation. Either both succeed or neither does. This is not optional when you're dealing with money.

"The architecture that survives isn't the one that looks cleanest in a diagram. It's the one that fails gracefully when things go wrong — and they will go wrong."

You only understand failure modes by creating them

You can read about multi-tenancy. You can read about JWT rotation. You can understand atomic transactions in the abstract. But there's a kind of understanding you only get from tracing a data leakage bug through four layers of abstraction at 11pm, finding the one queryset that forgot to filter by restaurant_id, and sitting with the fact that your first two architectural decisions were wrong.

Building Savor taught me that system design isn't about choosing the right technologies. It's about understanding the failure modes of every interface between them. The Razorpay integration fails if my webhook handler is slow. GPS tracking floods my database if the frontend isn't debounced. Multi-tenant isolation breaks if I filter at the wrong layer. None of these are things you learn by reading. You learn them by breaking them, badly, and having to fix it.

If you're in the middle of a solo project right now and it feels like the complexity is winning — it probably is, temporarily. That's what week three feels like. The tangle is the work. Push through it.

Live demo: food-delivery-seven-bice.vercel.app

Backend API: food-delivery-backend-c4pe.onrender.com/api

Github: food-delivery-github

Postman collection at backend/postman.json — all auth rotation, order status, and multi-tenant profile endpoints pre-configured.

I built a JSON CLI tool with Bun and TypeScript — here's what actually happened

siyadhkc — Mon, 11 May 2026 01:31:57 +0000

I wanted a tool that could flatten JSON, filter it, colorize output, and fetch from a URL — all from
the terminal. Something between jq and gron but with a cleaner, more intuitive API. So I built
jray. This is the honest post-mortem of how it went.

GitHub: github.com/siyadhkc/jray
Website:siyadhkc.github.io/Jray

Why I built it

Every time I'm debugging an API response or poking around some nested config file, I reach for jq.
And every time, I spend the first five minutes googling the syntax again. jq is powerful — genuinely
— but it's its own language, and unless you're writing complex transformations daily, that overhead
adds up.

gron is the other tool I kept coming back to. It flattens JSON into greppable dot-notation, which
is exactly what you want when you're trying to find where a deeply nested key lives. But gron is
read-only. You can't filter and get structured output back. You can't fetch from a URL. The color
situation is nonexistent.

So I scoped out what I actually needed:

Flatten JSON to dot-notation paths (a.b.c = value) so I can see structure at a glance
Filter by key pattern without learning a query language
Fetch directly from a URL so I don't have to curl | jray every time
Color output by default on TTY
Fast enough that it doesn't feel like overhead when I'm in the middle of something

Bun was the obvious runtime choice. Fast cold start, native TypeScript support, a built-in test
runner, and bun build --compile that bundles everything into a single self-contained binary. No
Node.js version headaches, no separate install step for the runtime.

How it's structured

I kept the architecture intentionally flat. No frameworks, minimal dependencies. The core logic is
split into focused modules:

flatten.ts — recursive flatten and unflatten. Takes a nested object and produces a map of dot-notation paths to primitive values. Unflatten goes the other direction.
filter.ts — glob-style pattern matching on the flattened keys. user.* gives you everything under user, **.id matches any id at any depth.
color.ts — ANSI color output. Keys in one color, values type-aware (strings, numbers, booleans each get their own).
fetch.ts — thin wrapper around Bun.fetch that handles the request, checks content type, and pipes the response into the flatten pipeline.
cli.ts — argument parsing and wiring. Reads from stdin, a file path, or a URL depending on what flags you pass.

The whole thing compiles down to a single binary:

bun build ./src/cli.ts --compile --outfile jray

No runtime dependency on Bun after that. You ship the binary, it works.

The problems I actually ran into

npm name conflict

First thing I did after writing the initial working version was try to publish as jray. Already
taken — and not squatted. An actual published package with actual users. So I had to switch to a
scoped package: @siyadkc/jray.

That sounds like a small change but it cascades. The README, the install command in all the
examples, the binary name in package.json, the GitHub Actions publish step, the Dev.to article
draft I'd already half-written — all of it needed updating. It also changes how users install it
slightly, since scoped packages require the @ prefix. Not a dealbreaker, but check npm before you
name your CLI.

Package size bloat

My first publish was heavier than it needed to be. Bun's compiled binary includes the runtime,
which is expected and fine. But the npm package itself had no files field, so it was packaging
everything — source maps, test files, the node_modules from dev, local configs. None of that
belongs in a published package.

Fix was straightforward:

"files": ["dist/", "README.md"]

That single field cut the published package weight significantly. Always define files. The npm
registry doesn't know what's dev and what's production unless you tell it.

Windows compatibility

I had a postinstall script that ran chmod +x on the binary. Works perfectly on Linux and macOS.
On Windows it throws and the install fails. I wrapped it in a try-catch and updated the docs to note
that Windows users should either run the binary path directly or use WSL. Not the cleanest solution,
but honest about the platform situation. Full Windows support is on the roadmap.

GitHub Actions for CI and publishing

The pipeline itself wasn't complicated — install Bun, run tests, publish to npm on a version tag.
But there's one specific thing that tripped me up: not using --frozen-lockfile in CI.

Without it, bun install in CI can silently update the lockfile, which means your CI might be
testing against different dependency versions than what you developed against. Always use:

- uses: oven-sh/setup-bun@v1
  with:
    bun-version: latest
- run: bun install --frozen-lockfile
- run: bun test

Publishing to npm from Actions requires setting NPM_TOKEN as a repository secret and passing it
through to the publish step. Once that's wired, releases are a tag push away.

What it actually does

# Install
bun add -g @siyadkc/jray

# Flatten JSON from stdin
echo '{"user":{"name":"Eliot","age":24}}' | jray
# user.name = "Eliot"
# user.age = 24

# Flatten a local file
jray data.json

# Filter by key pattern
jray --filter "user.*" data.json
# user.name = "Eliot"
# user.age = 24

# Fetch from a URL and flatten
jray --fetch https://api.example.com/users/1

# Disable color (for piping into other tools)
jray --no-color data.json

The filter uses glob-style matching against the full dot-path of each key. So user.* matches one
level under user, while **.id would match any id at any depth in the document. It's
intentionally simpler than jq's filter syntax — the goal is something you can remember without
looking it up.

Where it sits vs the competition

gron is the closest thing and the most direct comparison. It also flattens to dot-notation and
it's what made me realize there was a gap to fill. But gron has no color output, no URL fetching,
and no NDJSON streaming support. jray has all three.

jq is in a different category. It's a transformation tool — you write expressions, you reshape
data, you do complex operations. jray is an inspection tool. You throw data at it and you
understand the structure immediately. They're complementary more than they're competing.

fx is another one that comes up. Interactive, powerful, but it's a TUI. If you're in a script or
piping between tools, you don't want a TUI. jray is designed to be pipeline-friendly from the
start.

The longer-term vision is broader than just JSON. Supporting YAML and TOML with the same flatten
and filter interface makes it a universal structured-data CLI. There's also TOON (Token Oriented
Object Notation), which is an emerging format that's genuinely useful for LLM developer workflows
since it's optimized for tokenization. That's a real differentiator if the format gets traction.

The launch

Published to npm, wrote this article, posted on X . Also shared in the Bun
Discord since the community there is small enough that people actually read it.

The GitHub Pages site is live. It's getting redesigned right now — moving toward a flatter, more
minimal aesthetic with an interactive playground section where you can paste JSON directly in the
browser and see the flatten and filter output in real time. No install required to try it. That
single feature will probably do more for adoption than any amount of posting.

What I'd do differently

I'd define the files field before the first publish, not after. I'd also check npm for name
conflicts before I was emotionally attached to the name. And I'd set up the CI pipeline before
the first push to main so I wasn't debugging GitHub Actions at the same time I was trying to
ship.

The architecture decisions held up fine. Bun was the right call. The modular structure meant I
could add fetch.ts and color.ts without touching the core flatten logic. That's about as much
as you can ask from a first project's structure.

Try it

bun add -g @siyadkc/jray

GitHub: github.com/siyadhkc/jray

If you're working on something similar with Bun, or you have opinions on the filter API design,
drop a comment. Always curious how other people are solving the same problems.

This is my first article writing on this platform so if i made any narration mistake or anything feel free to tell me, i will improve my writing skill and the way of telling this
-- let's get connected --

From Hardware to Hacking: How Understanding Systems Changed My Approach to Security

siyadhkc — Wed, 15 Apr 2026 15:56:13 +0000

Introduction

I didn’t start my journey in cybersecurity. I started with hardware and networking, learning how systems actually function at a low level — how machines communicate, how configurations impact behavior, and how failures happen.

The Shift to Development

Later, I moved into development, working with Python and full-stack technologies. Building applications helped me understand how software is structured, but it also revealed something important:

Most applications are not built with security as a priority.

The Turning Point

This realization pushed me toward cybersecurity, specifically:

Web application security
API security
Cloud platforms (AWS, Azure, GCP)

Instead of just building systems, I began analyzing how they can be exploited.

A Different Way of Thinking

The biggest shift was in mindset:

From:
“How do I build this system?”

To:
“How can this system fail or be attacked?”

This dual perspective — builder and attacker — is critical in modern cybersecurity.

What’s Next

I’ll be sharing:

Practical security insights
Real-world learning experiences
Breakdowns of vulnerabilities and misconfigurations

If you’re interested in understanding systems deeply — not just building them, but also testing their limits — follow along.

I built a modern alternative to gron using Bun and TypeScript

siyadhkc — Sun, 12 Apr 2026 17:16:36 +0000

The problem

Working with JSON in the terminal is painful. jq is powerful
but requires learning a whole query language. grep works but
matches values too — not just paths.

For example if I search for "name" in my JSON:

grep matches json.user.name ✅ (correct)
grep also matches json.bio = "my name is Alice" ❌ (wrong)

So I built jray.

What jray does

jray flattens any JSON into one line per value:

$ jray data.json
json.organization.name = "Acme Corporation"
json.users[0].name = "Alice Pemberton"
json.users[0].role = "admin"
json.users[0].active = true
json.billing.plan = "enterprise"

Now you can grep it, awk it, pipe it — using tools you already know.

Four commands that cover everything

# Flatten with color output
jray data.json

# Fetch a URL directly — no curl needed
jray https://jsonplaceholder.typicode.com/users/1

# Filter by path only (never matches values)
jray data.json --filter "billing"

# Extract any subtree as clean JSON
jray data.json --select "billing"

# Print just the values
jray data.json --values

# Reconstruct original JSON
jray data.json | jray --ungron

The comparison with existing tools

Feature	jray	jq	gron
Flatten to lines	✅	❌	✅
Reconstruct JSON	✅	❌	✅
Filter by path	✅	✅	❌
Extract subtree	✅	✅	❌
Fetch from URLs	✅	❌	✅
Color output	✅	✅	✅
No query language	✅	❌	✅
TypeScript / modern	✅	❌	❌

What I learned building it

This was my first open source CLI tool. Key lessons:

1. Separate your CLI from your logic
cli.ts handles only I/O — reading files, printing output.
flatten.ts, filter.ts etc. know nothing about terminals.
This makes everything testable in isolation.

2. Use unknown not any in TypeScript
JSON is dynamic but that doesn't mean any. Using unknown
forces you to check types before using values — much safer.

3. Recursive functions are perfect for JSON
JSON is a tree. Walking a tree with recursion is the
cleanest pattern — each call handles one node and
delegates children back to itself.

4. Bun is genuinely fast and simple
Native TypeScript, built-in fetch, fast startup.
For a CLI tool, Bun is a great choice.

5. The README matters as much as the code
Nobody uses a tool they can't understand in 30 seconds.
Writing clear examples with real output is as important
as writing the code itself.

Install and try it

npm install -g @siyadkc/jray

Then:

jray https://jsonplaceholder.typicode.com/users/1

GitHub: github.com/siyadhkc/Jray

for more info Website: https://siyadhkc.github.io/Jray/

This is my first open source tool. Feedback on the code
quality is very welcome — especially from experienced
TypeScript developers!

DEV Community: siyadhkc

Why Most Django Boilerplates Are Insecure by Default

The Illusion of "Production-Ready"

What Actually Ships in Most Boilerplates

1. DEBUG = True Tied to an Environment Variable That Defaults to True

2. SECRET_KEY Hardcoded or Weakly Generated

3. ALLOWED_HOSTS = ["*"]

4. CORS Configured Wide Open

5. No Security Headers

6. Session and Cookie Settings Left at Defaults

7. Django Admin Sitting on /admin/

Why This Keeps Happening

What a Secure Boilerplate Default Looks Like

A Checklist Before You Ship

The Honest Takeaway

I Built a Pre-Commit Secret Scanner Because GitHub's Is Too Late

The problem with GitHub Secret Scanning (it's a timing problem)

Who this is actually for

What it detects

Getting started in 60 seconds

The pre-commit hook — the part that actually changes your habits

Handling false positives

CLI flags for different workflows

For teams: CI/CD as a second checkpoint

env-guard vs GitHub Secret Scanning — use both

The thing I keep thinking about

Try it

What's coming next

I built a multi-tenant food delivery platform alone. Here's what nobody tells you about that.

I was tired of building things that felt fake

These aren't exciting choices. They're correct ones.

Each portal was its own distinct problem

The struggles nobody writes about in project writeups

The one decision that saved the whole system

You only understand failure modes by creating them

I built a JSON CLI tool with Bun and TypeScript — here's what actually happened

Why I built it

How it's structured

The problems I actually ran into

npm name conflict

Package size bloat

Windows compatibility

GitHub Actions for CI and publishing

What it actually does

Where it sits vs the competition

The launch

What I'd do differently

Try it

From Hardware to Hacking: How Understanding Systems Changed My Approach to Security

Introduction

The Shift to Development

The Turning Point

A Different Way of Thinking

What’s Next

I built a modern alternative to gron using Bun and TypeScript

The problem

What jray does

Four commands that cover everything

The comparison with existing tools

What I learned building it

Install and try it

1. `DEBUG = True` Tied to an Environment Variable That Defaults to True

2. `SECRET_KEY` Hardcoded or Weakly Generated

3. `ALLOWED_HOSTS = ["*"]`

7. Django Admin Sitting on `/admin/`