Introduction
Recently, an external red team (security) discovered a unique vulnerability in an application I maintain.
All other work o...
For further actions, you may consider blocking this person and/or reporting abuse
Who is still bundling all the frontend code in one file? With all main browsers supporting dynamic imports it is a antiquated best practice.
Why have sensitive code in the frontend in the first place? When the code is sensitive it should be in the backend to have no exposure.
Lazy loading is not stopping that. API endpoints should have security measures in place to prevent that.
All javascript code send to the browser is public, so thinking it is possible to use it as a security measure sets you up for failure.
David, bundling code has been the default for a long time. I'm not saying it's current practice (i.e. Angular implements lazy loading by default), but there's a LOT of legacy code out there that can be improved.
There has to be "some" sensitive code in the frontend to reach the backend - API URLs, potentially keys, and possibly more with poor designs. Not all security should be in the backend.
Lazy loading absolutely can protect information if done correctly. I think it's naive to think otherwise.
The ultimate idea I am proposing here is to limit what protected information is visible and when. Ignoring what has to be done in the frontend because the backend is "secure" would be my idea of setting yourself up for failure. It all should be protected end-to-end.
Thank you for the thoughts ...
As I mentioned before API urls should have security measurements, otherwise lazy loading code is not preventing misuse.
If there is a man in the browser attack all the API urls can be exposed, and when they see the endpoints don't have security measurements there can be a data breach.
But even without an attack the filename of the lazy loaded modules can be found in the initial code and can be downloaded to find urls.
That is my worst nightmare, a key that can be found in javascript code. This is one of the reasons there is a backend/frontend divide.
You don't want people to make request with your key, this can lead to not being able to use the API because bots are hammering it with your key.
Lazy loading on its own doesn't protect information. It can defer asking for information, but that is security by hiding. And that is one of the weakest security measurements.
It is the same boat as frontend validation. If it is not backed up by backend validation, it is only half of a security measure.
I agree that the frontend can be responsible for a bit of the security tasks, but it should be the backend that evaluates when the situation is secure enough to push the information to the browser.
A website is loaded in many unsecured applications, so it is much easier to undo frontend security measures.
I think looking at in-browser behaviour as security without mentioning the backend side of the coin, is a dangerous way to promote security.
I'm never promoting frontend only. Just showcasing a pattern I found that improves things on the frontend. As I said previously, it has to be a holistic approach to security and ignoring the frontend because the backend is solid is just as bad as a frontend only approach.
I'm agreeing, not disagreeing.
I can sort of see this being valuable as part of defense in depth, but if that's the only thing preventing secrets being exposed then it's just security through obscurity, which is really no security at all. Secrets should never be included directly in code bundles, if they're present there then something's already gone badly wrong.
I would always advocate for defense-in-depth. In fact, I use the word secrets lightly. I’d rather not have the API endpoints in code, but it’s a necessity. I wrote this article as another layer I realized that might not be used as effectively as it could.
Great perspective!
It’s true that in large SPAs (especially with sensitive dashboards or admin modules), lazy loading can indirectly reduce the attack surface.
I’ve seen some WordPress-based apps using dynamic script injection for similar reasons — might be worth exploring cross-framework patterns like that.
Yes. I think I’ve got a lot of research to do. Thank you for the thoughts.
Thanks for sharing these insightful article.
You’re welcome!
This cover is amazing U w U
Thank you. I can't take too much credit - dozens of attempts at various options (in Canva).
Does lazy loading hide code, or just delay it until auth?
It doesn’t “hide” code. The code is not loaded until proper auth takes place. So, yes, the code is visible and potentially accessible at some point. This is one step in a security fence.
This is a very insightful exploration of using lazy loading beyond just performance optimization, extending it as a layer of security for frontend code.
Thank you. I like how you phrased this!
Very insightful information
Thank you. There's just enough content here for an article; not enough (yet) for a conference talk ...