How can I secure the infrastructure both at teh presentation as well as service layers?
An API-first strategy enables right from he start of the project, allowing multiple customer-specific presentation layers, Backend-For-Frontend patterns. Providing a UI first and opening up APIs to the public as an after thought is one way of architecting services but I take the rival approach.
As discussed in Part-1 of the series, a bad actor can craft a UI similar to my the one I offer and trick a user of my services to enter their valid credentials and initiate a session. Thought with the
http-only restrictions on cookies and the nature of browsers not letting unrelated domains access a cookie, there is the problem of the actor replaying state-changing (for eg.
DELETE) but valid requests to any of my services.
CSRF-Tokens help over the forms in UI, as I keep the API (Service Layer) open, there seems to be a possibility that the cookies could be passed on by the browser to this API layer which can do actions unintended by the actual user.
Several responses here express different viewpoints on how it is not relevant to certain applications, how it indeed is applicable and so on. What seems to be of use further is the Double Submit Cookie approach presented under a different name in this response.
Since we are going an API-first way anyway, the immediate need is to allow registrations via API indeed i.e
That way, an API user is the only one who has a way to access his resources.
As we implement UI, we start using Cookies to store these JWTs i.e
That way, the UI user is the only one who has a way to access his resources via UI.
Using another domain, demonstrate the possibility of (1) XSS atacks and (2) CSRF attacks over cookies and read the resources mentioned in Readings section](#Readings)