3 ms·
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
by 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.