40 ms·

Where can I learn/read about this topic? It seems like mysterious magic to me, and everyone is always saying everyone else is wrong.

brazzy 5y ago
Concernting this particular article, there is not actually much to learn. Ignore everyone bickering about CORS, that's beside the point (as is the title, which was very badly chosen). The point is that in a client-server architecture, you can never trust the client to play by your rules, and anything you put into the client becomes public knowledge. The big mistake in a previous article which this one criticizes is this: it put an API key hardcoded into the client, which let everyone who looks at the client code do whatever the REST API lets you do. At that point, rules like "you need an account, you have to log in, you can only change your own stuff" can simply be ignored by accessing the REST API directly instead of running the client code. The correct way to do it is to require an authentication token sent along with requests and which the server checks. The difference between the insecure API key and the authentication token is that the client gets the token only after the user logs in, it is unique to that user, possibly valid for a limited time, and the server will only only allow viewing or modifying things which the user for which that token was generated is allowed to view or modify.
chmod775 5y ago
> Where can I learn/read about this topic? It's not this specific topic, it's any topic and a general mindset. Thinking about possible attack vectors on your own application is a mindset, and to be able to do that properly you need to deeply understand the technology you are using. There's no exhaustive list of security issues to avoid, just as there is no exhaustive list of every function you'll ever need to write. Security means preventing the wrong kind of people to do the wrong kind of things. What that means is entirely dependent on your application. In the current webpack world where your code is mangled through 18 different tools before turning into an opaque JavaScript blob somewhere in your angular app that was automatically set up for you, many people lack an understanding of what's actually happening. You cannot make a boat sink-proof if you don't understand why a boat floats. Sure someone could make a list of things to watch out for and rules to abide by, but that's probably not gonna cut it in the long run.

brazzy 5y ago

Concernting this particular article, there is not actually much to learn. Ignore everyone bickering about CORS, that's beside the point (as is the title, which was very badly chosen). The point is that in a client-server architecture, you can never trust the client to play by your rules, and anything you put into the client becomes public knowledge. The big mistake in a previous article which this one criticizes is this: it put an API key hardcoded into the client, which let everyone who looks at the client code do whatever the REST API lets you do. At that point, rules like "you need an account, you have to log in, you can only change your own stuff" can simply be ignored by accessing the REST API directly instead of running the client code. The correct way to do it is to require an authentication token sent along with requests and which the server checks. The difference between the insecure API key and the authentication token is that the client gets the token only after the user logs in, it is unique to that user, possibly valid for a limited time, and the server will only only allow viewing or modifying things which the user for which that token was generated is allowed to view or modify.

chmod775 5y ago

> Where can I learn/read about this topic? It's not this specific topic, it's any topic and a general mindset. Thinking about possible attack vectors on your own application is a mindset, and to be able to do that properly you need to deeply understand the technology you are using. There's no exhaustive list of security issues to avoid, just as there is no exhaustive list of every function you'll ever need to write. Security means preventing the wrong kind of people to do the wrong kind of things. What that means is entirely dependent on your application. In the current webpack world where your code is mangled through 18 different tools before turning into an opaque JavaScript blob somewhere in your angular app that was automatically set up for you, many people lack an understanding of what's actually happening. You cannot make a boat sink-proof if you don't understand why a boat floats. Sure someone could make a list of things to watch out for and rules to abide by, but that's probably not gonna cut it in the long run.