I have always replied to colleagues who poohpoohed "security through obscurity!" as if it was proof of ignorance or bad culture with "a password is just a string of obscure characters. ;-)"

That's not a serious argument, of course. But consider how the spooks operate in the field. They employ all manner of obscure practices in an attempt to improve their security. Their intentional obscurity (AFAIK) is never allowed to unnecessarily complicate operational practices, which would introduce risk. And they've probably got a lot more theory and no-BS field testing behind their practices than we do.

Maybe we should ask them for advice?

This was largely true before. But AI reduces the cost of comprehension and finding vulnerabilities en-masse to zero, so this no longer holds, and I’m increasingly convinced that hiding in noise and complexity is no longer a valid strategy. But AI symmetrically makes it easier to secure your system so it’s not like all hope is lost even if the transition period will be brutal.

I wrote a blog about this: https://tanyaverma.sh/2026/03/01/nowhere-to-hide.html

In a corporate setting my experience is that it is rarely worth it to add any obscurity on top of security. Your biggest challenge is getting peoples time and resources, and you need to use that time to implement security controls. A secondary objective you have is to build security culture over time and teach people too see patterns where more security is needed, so it is important to select what to teach to get maximum impact.

Cixin Liu's Dark Forest theory is security through obscurity. If you don't have any other defense mechanism, at least try to hide.

And the second thing that bugs me about this interaction... Sure... "Security" is a process. It is a way of looking at things. It is proper use of tools and awareness of threat when designing software.

But it is also a set of trade-offs and relationships between architectural components. It worries me that this isn't displayed in the interaction described in the post

I remember when port knocking was discussed here on HN many years ago it was shit upon because people said security through obscurity is bad. What really frustrated me, at the time and still (when people shit on it), is that it's not just obscurity, it's also security. Port scans see nothing, but just knowing the port doesn't give you anything. You still need a password or key.

Couldn't one argue that a password is also obscurity? It's only secure until someone figures it out, just like a secret URL on a website.

The problem with security through obscurity (even if it’s just an “addon”) is that it pollutes your code base, system. It’s just not worth it.

Like moving ssh to a different port. If you are the only one working on it, sure fine, as long as you remember the port. If you re working with others, then everyone needs to know the new port, so it has to be documented somehow. It’s a pita

It's useless for the example given because obfuscating JavaScript as protection no longer has any purpose, if you can let AI analyze the code, and/or in this case the API requests.

I recently did use a variation of this type of security to prevent a malicious user misusing our services... But I made a not to me an everyone else it was just a quick fix not guaranteed to work long term.

The problem with obscurity is that it breeds complacency; the implementer is often uninformed or assumes it protects everything else.