Skip to content

feat(withXSRFToken): added withXSRFToken option as a workaround to achieve the old withCredentials behavior;#6046

Merged
DigitalBrainJS merged 36 commits intoaxios:v1.xfrom
DigitalBrainJS:feat/xsrf
Nov 14, 2023
Merged

feat(withXSRFToken): added withXSRFToken option as a workaround to achieve the old withCredentials behavior;#6046
DigitalBrainJS merged 36 commits intoaxios:v1.xfrom
DigitalBrainJS:feat/xsrf

Conversation

@DigitalBrainJS
Copy link
Collaborator

@DigitalBrainJS DigitalBrainJS commented Oct 30, 2023

Since automatic XSRF token sending when the withCredentials option is set has become considered a vulnerability, although it could be disabled, the only practical solution is probably to add a separate option to control the sending of the token.
So now the user must explicitly set withXSRFToken to true to send XSRF token to third-party origins.
By default withXSRFToken is undefined - the token will be sent only to the same origin.
You can set it to false to disable setting the header at all. In practice, this is the same as setting xsrfCookieName or xsrfHeaderName to falsy.
To migrate from the old withCredential behavior (<v1.6.0), you should now use withXSRFToken along with withCredential.
You can emulate the old unsafe behavior with just one line:

axios.defaults.withXSRFToken = (config) => !!config.useCredentials;

See #6028

📢 This PR added 'withXSRFToken' option as a replacement for old withCredentials behaviour. 
You should now use withXSRFToken along with withCredential to get the old behavior.
This functionality is considered as a fix.

� Conflicts:
�	package-lock.json
�	package.json
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants