1

In the backend I am currently working on I have a servlet (call it S) and a WebSocket endpoint (call it E). S needs to communicate with E, yet, as of now, any WebSocket client may connect to E.

My question is: how should I name the URI of E and how can I enforce that only S is allowed to communicate with E (if that is possible in the first place).

(I am interested in any answer, approximated or exact.)

coderodde
  • 113
  • 4

2 Answers2

2

While I agree with the previous answer that naming should not be considered a strong security control, I would suggest that you avoid naming things in an overtly obvious manner (i.e. "ThisServerHostsMyCrownJewels.company.local" :) )

In terms of how to allow only 'S' to talk to 'E', that is a technical question for which a lot more detailed information on what platforms, versions, etc. are in use. The short answer is it could be done via traditional firewalling, or using IPTables or configurations in the WebSocket server, or perhaps more preferably a combination of two or more of these.

Sean E. M.
  • 126
  • 5
  • 4
    This can make debugging a hell of a lot harder, especially if the documentation is incomplete. You have to weigh the security benefits of using "obscure" names to against the convenience of using self-explanatory names. –  Dec 02 '19 at 13:24
  • I am not sure which portion you are suggesting would make debugging harder, but it is typically best practice to do debugging on Dev or QA systems, not production. – Sean E. M. Dec 02 '19 at 13:28
  • 2
    Yes, you should obviously debug in dev or staging, but imagine the situation of a new sysadmin, having to get used to hundreds of abbreviations, because to them, they're just as obscure as to the attacker. This directly translates to costs to the company, as it takes a new hire *much* longer to understand a complex system. –  Dec 02 '19 at 13:30
  • 1
    Self-documenting code -> Infrastructure as code -> self-documenting infrastructure – schroeder Dec 02 '19 at 13:38
1

Naming should have nothing to do with security, as security by obscurity should not be your goal. Instead you should find a way to authenticate the user (using a passphrase, a challenge...)

Betcheg
  • 240
  • 1
  • 2