I Tried to Hack My Own PaaS... Here's What I Found (HYNA-Stage v2.5.0 Security Audit) 🔒🪔
DEV Community

I Tried to Hack My Own PaaS... Here's What I Found (HYNA-Stage v2.5.0 Security Audit) 🔒🪔

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
Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.