Issues with allowing the frontend to determine which Javascript is delivered by server?

Current situation

My company has a ton of different environments where it's not always easy to deploy front end code to test against working/live data. We use an extension to swap out certain scripts being sent from the server with those available locally. This mostly works but comes with some limitations.

Desire

A few years ago, I worked at another company that allowed us to run a command in the browser console that did the same thing as the extension. I didn't look at the time how it was implemented, but I believe it had something to do with having basically a small javascript package that was first sent to the browser that determined which package should be delivered and if a value in local storage was marked "true" it would place script tags pointing to localhost. If it was false, it would go to the server instead.

Question

I want to implement something like this at my current company but I am curious as to the security implications of it.

Solution 1:

As long as the JavaScript packages being served don't contain any sensitive information, it should be fine.

If the packages being served do contain sensitive information, they're likely deserving of refactoring - it'd be better to only serve sensitive information after the backend authenticates that the user is authorized to receive it, rather than to serve it to anyone that happens to request a package through the front-end package manager.

When considering security, a good rule of thumb is to act as if the client can read the client-side JavaScript, and modify and execute it as desired. So, any verification steps should be done on the server, not on the client.

If the only thing you're thinking of implementing is

if a value in local storage was marked "true" it would place script tags pointing to localhost. If it was false, it would go to the server instead.

then that's perfectly fine - the worst clients could do by tampering with that is to run their own JavaScript (which they can do already).

If this is intended to make things easier for developers to test the live site, a better approach might be to completely separate the live production environment from the development environment - set up a development server with dummy data and fewer restrictions that the developers can interface with, while clients can only see the production server (which now may not benefit from having a front-end script manager anymore).