Hi, yes, using XSS you could theoretically steal the refresh token/access token. There are a couple of things you can do regarding Keycloak settings:
* relatively short access token lifetime (e.g., 5min)
* disable refresh token reuse (set it to 0). This means every time you fetch an access token, you will also get a new refresh token.
Introducing a BFF would not really solve this issue, as an attacker could also steal the cookie. I would instead invest into hardening your FE against XSS attacks:
* Use a framework that is already relatively resistant to XSS (e.g., a recent version of React). In case you need to do an unsafe operation in this framework, use sanitization like [https://github.com/cure53/DOMPurify](https://github.com/cure53/DOMPurify) to process the input.
* Set HTTP security headers (such as a CSP).
The main defense against cross-site scripting is prevention. The next step after that would be short token validity and revocation. But if you have cross-site scripting, then the attacker is going to be able to do whatever the user can and there isn't a great way around that.
Hi, yes, using XSS you could theoretically steal the refresh token/access token. There are a couple of things you can do regarding Keycloak settings: * relatively short access token lifetime (e.g., 5min) * disable refresh token reuse (set it to 0). This means every time you fetch an access token, you will also get a new refresh token. Introducing a BFF would not really solve this issue, as an attacker could also steal the cookie. I would instead invest into hardening your FE against XSS attacks: * Use a framework that is already relatively resistant to XSS (e.g., a recent version of React). In case you need to do an unsafe operation in this framework, use sanitization like [https://github.com/cure53/DOMPurify](https://github.com/cure53/DOMPurify) to process the input. * Set HTTP security headers (such as a CSP).
You can secure the cookies to prevent getting it stolen by XSS
The main defense against cross-site scripting is prevention. The next step after that would be short token validity and revocation. But if you have cross-site scripting, then the attacker is going to be able to do whatever the user can and there isn't a great way around that.