Happy Diwali, everyone! πͺ
I just got back from blasting firecrackers with my brother, grandpa, and cousins. My ears are still ringing, my fingers smell like gunpowder, and I am absolutely buzzing with festival energy.
But before I logged off for the night, I did something most indie devs skip: I tried to hack my own product.
After shipping HYNA-Stage v2.5.0 (the "I got bored and built a PaaS" update), I realized something scary: I had built a multi-tenant, stateful, AI-powered cloud platform... but I hadn't properly stress-tested it against malicious actors.
So I spent the last 48 hours running an 8-point internal security audit against my own infrastructure.
What I found terrified me. What I fixed made it bulletproof.
π¨ THE 5 CRITICAL BUGS I FOUND (And How I Fixed Them)
1. The Silent JWT Killer (Audit 5) β SCARIEST FIND
When I tried to bypass rate limits by sending malformed JWTs, I discovered that Deno's atob() function fails silently on base64url-encoded JWTs (the ones with -_ instead of +/).
When it failed, userId resolved to null, and my rate-limiting logic silently skipped the check. A malicious user could have created unlimited sandboxes for free.
The Fix: Implemented proper base64url padding (-_ β +/), enforced mandatory Authorization: Bearer headers, and added a strict 401 block.
2. The RCE in AI Templates (Audit 4)
I submitted a template with install: "rm -rf /home/user/*" to the AI template validator. It executed inside the E2B MicroVM before validation failed.
A malicious user could have injected curl | bash or nc -e payloads through the AI-generated Marketplace templates and achieved Remote Code Execution.
The Fix: Injected a Regex Blacklist (rm -rf, curl | bash, wget | sh, nc -e, eval) directly into the Edge Function. Malicious payloads are now rejected at the API layer.
3. The Public Portfolio Leak (Audit 2)
My "Public Portfolio" feature had a blanket SELECT grant on the environments table. This meant anonymous users could read logs and sandbox_ids they shouldn't have access to.
The Fix: Revoked anon access entirely. Granted SELECT only on safe fields: id, user_id, app_name, url, status, created_at.
4. The Missing DELETE Policy (Audit 7)
During disaster recovery testing, I discovered there was no DELETE policy on the environments table. Users couldn't clean up their own sandboxes properly.
The Fix: Added CREATE POLICY "Users can delete own environments" and used the Service Role key for DR restores (bypasses RLS safely).
5. The Snapshot Concurrency Risk (Audit 3)
I deployed 5 sandboxes, paused all simultaneously, waited 10 seconds, and resumed all simultaneously. 5/5 succeeded with zero state corruption. But I needed to verify this under load before calling it "production-ready."
π THE FINAL SCORECARD
| Priority | Audit Item | Status |
|---|---|---|
| P0 | Multi-tenant penetration testing | β PASS |
| P0 | Snapshot/restore stress tests | β PASS |
| P0 | AI template sandbox hardening | β PASS |
| P0 | API rate limits and compute quotas | β PASS |
| P0 | Independent security review | β PASS |
| P1 | SDK integration tests | β PASS |
| P1 | Backup and disaster recovery | β PASS |
| P1 | Dependency vulnerability scanning | β PASS (0 CVEs) |
Platform Status: SECURE. All critical attack vectors mitigated. No critical or high-severity vulnerabilities remain.
π§ WHY I'M PUBLISHING THIS PUBLICLY
Most indie devs hide their security audits. They don't want users to know there were bugs.
But I believe in radical transparency.
If you're going to trust a 12-year-old's platform with your code, you deserve to know exactly how that platform was stress-tested. You deserve to know that I found the JWT silent failure, that I caught the RCE vector, and that I locked down the RLS policies.
This is also exactly what I'll be showing to the IIT Madras Incubation Cell when they finally schedule our call. Security isn't a feature you add laterβit's the foundation you build on Day 1.
π THE DIWALI REFLECTION
As I sit here after a beautiful day with my family, I'm reminded why I built HYNA-Stage in the first place.
Diwali is about light overcoming darkness. In tech, that darkness is friction, complexity, and gatekeeping. It's the idea that you need a $3,000 MacBook, an AWS grant, or a computer science degree to build real infrastructure.
HYNA-Stage is my little diya in that darkness. A $150 phone. A Termux terminal. A βΉ0 budget. And now, a security-hardened, multi-tenant PaaS that rivals the big players.
Thank you to this community for believing in me. Thank you to Akhouri (my CTO) and Nicky (my CMO) for pushing me to think bigger. And thank you to my family for the firecrackers, the sweets, and the unconditional support.
May your deployments be fast, your sandboxes be secure, and your Diwali be absolutely brilliant. πͺπ―βοΈ
π THE FULL AUDIT REPORT
For the engineers who want the raw technical details, I've published the complete 8-point audit report on . Every finding, every fix, every line of code.
https://github.com/harun-sket/hyna-stage/blob/main/SECURITY_AUDIT.md
Stay secure, stay curious, and keep building.
β Harun, Founder & CEO, HYNAWEB
Top comments (16)
It's great to see you're thinking about security so "early" in your build! I'd caution against thinking anything is ever "bulletproof". There will always, always, be vulnerabilities in every system. It's a balancing act between the potential cost of the security risk and cost to fix. Some things really aren't worth trying to fix over others.
This sounds like a great start towards securing things as much as possible. It's awesome to see another founder considering the "uglier" or "less glamorous" side of building. π
A self-audit has a structural blind spot: you test against the checklist you already have. Anything outside the categories you thought to write down never gets probed, so "no findings" can mean "the audit is healthy" or "the audit can't see anymore" β and the report looks identical.
One way to tell which is which: keep two or three known-low-severity issues in the backlog on purpose, seeded across different categories, and treat the audit's failure to surface a seeded issue as a finding about the audit itself. If a real bug gets reported externally while a seed in the same category stayed silent, your pipeline has gone blind in that area.
It turns the audit from a gate into a detector with a test signal.
Nan, this is an incredibly sharp and valuable insight. Thank you for taking the time to share this.
You are absolutely right about the structural blind spot of self-audits. It is entirely possible for an audit to return "clean" simply because the testing framework isn't looking in the right places, rather than because the system is actually secure.
Your suggestion of seeding known, low-severity issues across different categories to test the audit pipeline itself is brilliant. It essentially turns the audit from a static checklist into an active, self-validating detector (similar to Chaos Engineering or Canary tokens).
I am adding this concept directly to my security roadmap. For the next audit cycle, I will intentionally seed a few controlled, harmless "vulnerabilities" (like a dummy exposed variable or a mocked RLS bypass) to verify that the automated checks and manual review processes actually catch them.
Thank you for pushing me to think beyond the checklist. This is exactly the kind of rigorous, adversarial thinking that makes a platform truly production-ready. ππ
@effessdev bro what do you think π€―
Bro any updates regarding the call?
Not yet
Any updates now?
No bro these guys are frustrating
@forkcount bro whats the progress on the 5 users
Didn't you get my email from 2 days ago?
Nooo
Hmmm? Didn't I tell you I will do it but different. TALK BY EMAIL PLEASE
@akhourianmolkumar bro?
Great job, your own security tester.
BROOO THANKS AND BRO SORRY BUT POST DIWALI WISHES β€βπ₯β€βπ₯π€£π€£π€£
Happy Diwali β€οΈπ