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.
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?
- Change the CSP directive to include a malicious domain
- 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.