I'd like to know in general which of the two types of security is the best in all aspects that may refer to security (we can use this the general aspects for security: integrity, availability, authenticity and integrity).

Maybe there is some study that summarizes all of that.

Right now, I've mixed feelings about this.

I'm not expert in information security but, although as a general rule I think it's easier to bypass security measures that are on client side, it's also not impossible to tamper a data package that the server might send to determine if something can be done or not, and, in general, if an user manages to bypass the security measures set in local he might be able to do some malicious activity for himself, and by sharing it with others, with time, it could expand, but if he somehow gets access to the server, he can cause way more damage than he would have done in that way, as he could make all the security measures to be bypassed not only by himself, but by an huge amount of potential users, without any need to share.

I'm not sure if this is too broad for the site, but I'm posting to check if there's some summarized answer to that.

  • In general, security should always be done on the server-side. Why? Because you control the server, but you don't control the client. "Security" on the client side are at best beneficial to the UX (e.g. checking if a password has enough entropy, pre-calculating a KDF, etc.).
    – user163495
    Apr 3, 2019 at 13:57
  • 8
    You left out the most important detail that would determine where technical controls need to be placed: what are you securing?
    – schroeder
    Apr 3, 2019 at 13:58
  • 1
    It's just a general question for curiosity. @MechMK1, yes it's true that you control the server, but as I'm telling it's not impossible to tamper the data sent by the server, and if the attacker gets access to the server the more security you have set in it, the more undesired results for security you are going to get if the attacker has very malicious intentions. My point is if, in general, server-side security compensates ,even when taking into consideration these possible drawbacks, or not. Apr 3, 2019 at 14:03
  • By "tamper the data sent by the server", do you refer to a "man-in-the-middle" attack? If yes, then there are ways to prevent this sort of attack. Further, if an attacker gets access to your server by exploiting a vulnerability, then client-side security will likely not help you, as the client can't differentiate between legitimate server behavior or attacker behavior.
    – user163495
    Apr 3, 2019 at 14:06
  • @MechMK1, maybe I'm saying nonsense, as I said I'm not an expert on information security, but as tampering I wanted to mean that there are tools that allow to intercept and change the content of a tcp/ip packet in your client machine, for example Trudy software: blog.susanka.eu/… looks like it's able to do it, sure, the data can be encrypted and whatever, but it wouldn't be impossible to change the data to another desired one. Apr 3, 2019 at 14:18

2 Answers 2


Server-Side Security is better

Why? As I have stated in a comment, the big difference between server-side security and client-side security is the fact that you control the server, but not the client.

An example

Imagine a simple setup with a server exposing an API, and a smartphone app, which uses the API to display data and do other things.

Imagine the application would be designed to just not show you a button that would give you access to sensitive information, such as an admin interface. An attacker could simply debug the application and set isUserAdmin = true;, and have access to the admin interface. No amount of obfuscation would help you, as the client itself is the one making the decision and the client can be modified by the attacker as they want.

If, on the other hand, the server were to be the one making the decisions, then an attacker could attempt to modify the app to display the admin interface, but any actions within this interface would be rejected by the server.

Answering some questions

What if the attacker tampers with the data sent by the server?

This is called a "man-in-the-middle" attack and can be prevented if the server can authenticate itself to the client. While not getting into a lot of detail, the server has a secret key, which can be used to sign messages. An attacker can modify those messages, but they cannot forge a valid signature without knowledge of the key. A client would be able to detect that the message has been tempered with, and dismiss it.

You might say that an attacker can modify the client to accept the message, but at this point an attacker would only be able to attack themselves (or anyone who's client they can modify), which is not very useful.

What if the server is compromised?

This is a legitimate concern. Let's take HTTP Content Security Policy as an example: CSP tells the client from where what kinds of content is allowed to be loaded. For instance, JavaScript may only be loaded from the same origin (aka. your server). If an attacker compromises the server, they can:

  • Change the CSP directive to include a malicious domain
  • Change the deployed JavaScript to include malicious functionality
  • Disable CSP altogether

No amount of client-side security would help in this situation, as the client is instructed to only trust the server. Since the server is compromised, this basically instructs the client to trust the attacker.

What about tools like Burp or OWASP Zap?

The asker mentioned that tools like Burp or OWASP Zap can be used to modify the content of TCP/IP communication on-the-fly, even ones secured by SSL/TLS.

Yes, they can, but the client needs to cooperate. They work by acting like a proxy. Instead of the client communicating directly with the server, the client communicates with Burp, and Burp communicates with the server.

In order for this to work, the client needs to set Burp as their proxy either within their browser or as their system proxy. Further, in order to read and modify SSL/TLS traffic, Burp needs to install a root certificate on the client machine. If a user is legitimately trying to use Burp to, for example, debug an application, then they will of course install the certificate, as they are the one's controlling Burp.

If an attacker would try to act as a proxy for an unsuspecting victim, the browser will print an SSL error, and depending on the configuration of the website (e.g. using HSTS), the browser will completely refuse to connect.

Is Client-Side Security worthless?

Despite what it may have sounded like, no. Client-side security has its place as "defense in depth". It allows clients who "play nice" to have a bit more security in certain scenarios, but don't use it as your sole line of defense.


Security is not all about authentication and authorization on the server. Think about client-side buffer overflows for example, or denial of service, etc. Systems can be complex and threats can also target client-side code.

Imagine if WhatsApp had a vulnerability that allowed an attacker to infect the client by sending the victim a malicious message. You wouldn't be able to fix that on the server. In this case a server-side filter wouldn't even be possible by the way, since WhatsApp is supposed to use end-to-end encryption. Recently Apple FaceTime had a bug that allowed people to call somebody else and eavesdrop on them, and that was a client-side bug as far as I know, that required an update. Anyway, these were just examples to show you that in general security is important for every part of a system, and that client-side security doesn't only mean "sending valid parameters".

You must log in to answer this question.

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