I've recently encountered a developer who thinks that she can implement security on the client end of a web application. Breaking the security is as trivial as reading a few lines of Javascript and changing a URL.

In other words, the "security" of the application is entirely a facade. I know the vulnerability in question is a form of unchecked input parameters, but there's something deeper going on here, since the developer in question was told to make a security layer that couldn't be tampered with, and instead made something that's just a UI that LOOKS like it's secure.

It occurs to me that it would be useful to have a term for this. We already have "security through obscurity", and "security theater" to describe other behaviors people engage in they think is security. Is there any term yet for this? Security Facade is the best I can come up with.

  • 1
    "Breaking the security is as trivial as reading a few lines of Javascript and changing a URL." would be "security through obscurity". Having no security whatsoever but making it appear that you do would be similar to a security logo on your house window, or a sign that says "Beware of Dog" when you don't have a security system or a dog. A visible fake camera would be the same idea. I suppose those would simply be "deterrents".
    – TTT
    Nov 17, 2015 at 20:04
  • 1
    Could you explain why this situation is not covered by "security by obscurity" and "security theater?" That will emphasize the exact component you wish to label. Nov 17, 2015 at 20:06
  • 2
    "Client-side security" should suffice - it includes the underlying assumptions about what one can do on the client-side
    – schroeder
    Nov 17, 2015 at 20:07
  • 2
    SteveSether This is as @schroeder said, absolutely "client side security" - which is a subset of "Security Theater", and in some cases "Security by Obscurity". That said, other than giving it a name, this question does not have much "meat" to it... I'm sure you have other questions around this design (anti)pattern to flesh it out a bit more? So we dont have to close it... E.g. how to explain it to that developer?
    – AviD
    Nov 17, 2015 at 20:43
  • 2
    SteveSether - that seems more of a topic for the meta site. Nov 17, 2015 at 22:02

5 Answers 5


What about : Security Theater?

Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it. Some experts such as Edward Felten have described the airport security repercussions due to the September 11 attacks as security theater.

While it may seem that security theater must always cause loss, it may actually be beneficial, at least in a localized situation. This is because perception of security is sometimes more important than security itself. If the potential victims of an attack feel more protected and safer as a result of the measures, then they may carry on activities they would have otherwise avoided. In addition, if the security measures in place appear effective, potential attackers may be dissuaded from proceeding or may direct their attention to a target perceived as less secure. Unsophisticated adversaries in particular may be frightened by superficial impressions of security (such as seeing multiple people in uniform or observing cameras) and not even attempt to find weaknesses or determine effect.

Putting a lot of validation on the client side is similar to that. Most people will think that the site is secure when in reality it is not. If you don't really care about security and just want to dissuade lazy attackers then it might not be a bad idea.

  • I thought this was ruled out in the original post...
    – TTT
    Nov 17, 2015 at 21:01
  • @TTT, the OP ruled out Security Theater based on their understanding of it, which may or may not be correct.
    – Th4t Guy
    Nov 18, 2015 at 0:36
  • @Th4tGuy - I agree, however this answer is worded in such a way that they didn't realize it was ruled out. (Unlike Darkstar's answer.)
    – TTT
    Nov 18, 2015 at 3:16
  • 1
    @TTT Just because the OP rules it out doesn't mean that it's the wrong answer. Often you have to contradict the OP to give the right answer.
    – Gudradain
    Nov 18, 2015 at 3:30
  • @Gudradain - I agree. My point is simply that the first sentence says, "What about security theater? As if you didn't realize OP had already suggested it. I think perhaps your first sentence should say, "Even though you don't think "security theater" applies here, it actually does apply here, because...."
    – TTT
    Nov 18, 2015 at 16:38

Unauthorized Data Access at Server

I suggest you're thinking about this problem backwards. The vulnerability is at the server, and therefore, you should just call as you see it.

Obfuscation is a type of Security Through Obscurity; there's nothing inherently wrong with it unless you believe it more secure than it really is (like your colleague). Client side validation checks are also recommended as they improve responsiveness and reduce server impact, although relying solely upon them is insecure. The flaw is not with the client, but with the server. Don't name the client side "failure", as there isn't one. Instead, name the server side failure which is a missing data verification check (be it a boundary check or an access check).

In this case, the flaw is the missing check, which you know you can expose by crafting your own mini JS hack from a web browser. The moment you demonstrate it theoretically or actually, your team will understand what you mean when you point them at the security hole in the server.


All these terms have a lot of play in the joints, of course. But I think I tend to agree with the question author here: I would hesitate a little to use the labels "security theater" or "security by obscurity" re. the situation the OP offers up. "Security theater" is most often applied where the person who puts or keeps the supposedly effective security measures in place actually knows that they are weak & flawed in reality. Instead, here it seems like the source is simply just ignorant of the real security implications of what she wants to do. As for "security by obscurity", to channel Orwell I think one can argue that that term has been so over-used in the security community at this point that it has lost most of its original, useful meaning. At any rate, it's a term I personally try to avoid using except where it unquestionably applies. ("Why do I think WhirlyBirdBSD is the most secure OS? Well, since there are 700 people in the world that run it nobody ever targets it.")

As for how one might categorize this situation as instead, from technical & practical standpoints I'm with @Schroeder & others who suggested simply ""client-side security" as the category of failure/label. An excellent, concise way of putting it.

More generally, colloquially, & facetiously ... perhaps call it an UROASM failure: Unfortunate Reliance On A Security Myth. :) Category includes tons of other bad practices based on common-but-completely-wrong assumptions. (For eg., not caring about whether the OS on your PC gets patched because you use anti-malware software, which will surely protect you from anything that could be harmful. Or thinking you're safe from SQL injection because you escape user input.)


Security facade sounds like the most elegant choice. In this case the security is nothing more than skin deep and really provides only limited protection against the most lackadaisical script kiddies.

  • Security facade could be confused with the facade design pattern, which is a legitimate software design choice (and might actually be architecturally effective). 'Security Theater' is a much better word choice as it's already in the vernacular with the commonly understood meaning of "providing the illusion of security without effectively impacting security." Nov 17, 2015 at 23:19

I would like to offer up another approach: Security Gaffe.

This is not necessarily an industry term, but all uses of the phrase that I see in the media imply a similar definition:

  1. The creator/provider generally thought their system was secure enough.
  2. An unintended security mistake was made.
  3. The mistake that was made goes against industry best practices, and thus could probably have been easily avoided.

The main difference with this approach is that the "Gaffe" is not a flawed way of thinking about the problem, but instead it represents the flawed implementation resulting from the flawed thinking.

As a side note, when doing a quick search for "Security Gaffe", all the uses of the phrase are related to a security breach resulting from a security gaffe, but I believe the gaffe is there regardless of whether it is exploited or not.

Not the answer you're looking for? Browse other questions tagged .