Is the reverse-engineering of SPA components ever a risk?

Question

In a typical Single Page Application (SPA, ex: React), the entire code bundle is served up to the client. This includes private components of the app, which are often protected with a client-side authorization mechanism (for example, checking if an auth token is set in state).

Wouldn't it be possible to reverse-engineer these private components, and see at least their skeleton?

I understand that data would still be hidden behind the API, so an adversary wouldn't be able to see anything but the skeleton of the component (anything in code and not remote data: layout, copy text, interface behavior, etc.)

In contrast, SSR apps will most often not give you back any part of a protected UI if you're not duly authorized.

I understand that this is not a concern in most applications, but could it be a problem in apps that are completely private (eg, apps with no public sign up), where the interface could provide an adversary with valuable nuggets of information?

Is this ever considered as a disqualifying problem by teams with ultrasecretive requirements? (ex: military, or a stealthy startup) Or could they still use SPAs with some additional measures? (ex: don't serve the app to users outside of a trusted network)

Answer 1

This is a very good question indeed. Many frameworks will send templates or - as you name them - stubs. This is usually the default behaviour in the systems we build. I know of no case or project, where this would be considered to be a security flaw.

On the other hand I can imagine, that even a template/stub could be considered sensitive data usually either by an over-protective information security officer or simply because someone hardcoded sensitive data into them. So the question should be: what data is present in the stubs and how is it classified?

I believe this could be a good question to ask to a neighbourhood security officer and a good point to speak with the dev team too.