Protect ya front door

Wu-tang clan said it. To really protect ya neck you need to think about the threats out there that can affect all your yolo’d contraptions. If Claude Code can whip you up your latest “enterprise” agentic application, then imagine what a reverse engineered approach to pick apart your application can expose; basically as quickly as you can yolo that app together, someone else can pull it apart with even a small LLM even quicker.

The single page application (SPA) revolution has spoiled us when it comes to instant gratification of building business applications quickly, having it hold state, business logic, APIs, and integrations, etc… and then delivering APIs are purely stateless transaction layers. This isn’t a bad approach, the majority of secure enterprise applications are built this way and that’s fine.

Where this becomes interesting is we have to remember: if the browser can render your application and all its logic, then it wasn’t really “encrypted” or “compiled”; and this is really the important part. Remember this stuff exists on the frontend, that’s your CSS, HTML, and the JS bundles that contain all of your application.

Why small LLMs?

As LLMs are getting bigger and harnesses are getting tighter, ever in the push for more “ethical” AI (or “you get a castrated version unless you’re important or rich enough”), picking apart bundles, even if they’re your own, triggers safe guarding flags in harnesses. However, with smaller models they do less thinking, and generally the less one thinks the more they’re happy to do.

I don’t think, therefore I do

Go ahead and try it, go and give a small LLM your compiled JS bundles and ask it to pull it apart. It’s funny because there’s such a push towards the more capable, bigger, frontier models, but sometimes simple solutions solve complex problems.

It’s important, as part of your deployment process, you’re having some sort of belts-and-braces process that checks your exposed frontend code for the normal things:

• Are there credentials there?
• Did you add correct auth for your APIs?
• I hope you’re not storing your auth somewhere that exposes you to XSS!
• Omg is that customer data?

There’s some great hog and leak detection libraries out there that you can integrate to your CICD process. But this still doesn’t stop the leaking of your business logic, because that’s based in your bundle that’s needed on the front.

It’s good to be lazy

I’m a performance addict, and you should be too. We’ve seen some (thankfully) great advances in browser technology over the last two decades. One of the most important is proper async ability to import modules just in time. This is your saving grace.

If you have your APIs behind auth, then why not your bundles? Split your code, have your unauth’d bundle available, keep it small, then when auth is successful you then import the rest of the bundle with all your app’s business logic via an authenticated route. This also gives you a nice performance boost too, isn’t that nice?

Many build tools support this, it takes a bit of wiring and you need to know what you’re doing but there’s 1000s of posts on this, or you can just get your copilot to do it and hope for the best.

Anyway, this is just one small step to keep your bundles secured, stop exposing yourself and your logic, and hopefully protect ya neck. Fingers crossed.