Why are sessions not appropriate for CORS?
The question is just same as the title.
I was following a tutorial( from Thinkster ) about Django Rest Framework, one content about the authentications of which says like below.
"
In our case, the client and the server will be running at different locations. The server will be running at http://localhost:3000/ and the client will be at http://localhost:5000/. The browser considers these two locations to be on different domains, similar to running the server on http://www.server.com and running the client on http://www.client.com. We will not be allowing external domains access to our cookies, so we have to find another alternative solution to using sessions.
If you're wondering why we won't be allowing access to our cookies, you should check out the articles on Cross-Origin Resource Sharing (CORS), and Cross-Site Request Forgery (CSRF) linked below. If you just want to start coding, check the boxes and move on.
"
Here I read all the materials recommended here, MDN documents about CORS and CSRF, but can't still understand reason I shouldn't use sessions if I use CORS and CSRF here.
I even found some pages saying that if I change the 'withCredentials' Field to be 'true', then I can adhere to sessions.(CORS requests with session/cookie)
session django-rest-framework cors
add a comment |
The question is just same as the title.
I was following a tutorial( from Thinkster ) about Django Rest Framework, one content about the authentications of which says like below.
"
In our case, the client and the server will be running at different locations. The server will be running at http://localhost:3000/ and the client will be at http://localhost:5000/. The browser considers these two locations to be on different domains, similar to running the server on http://www.server.com and running the client on http://www.client.com. We will not be allowing external domains access to our cookies, so we have to find another alternative solution to using sessions.
If you're wondering why we won't be allowing access to our cookies, you should check out the articles on Cross-Origin Resource Sharing (CORS), and Cross-Site Request Forgery (CSRF) linked below. If you just want to start coding, check the boxes and move on.
"
Here I read all the materials recommended here, MDN documents about CORS and CSRF, but can't still understand reason I shouldn't use sessions if I use CORS and CSRF here.
I even found some pages saying that if I change the 'withCredentials' Field to be 'true', then I can adhere to sessions.(CORS requests with session/cookie)
session django-rest-framework cors
add a comment |
The question is just same as the title.
I was following a tutorial( from Thinkster ) about Django Rest Framework, one content about the authentications of which says like below.
"
In our case, the client and the server will be running at different locations. The server will be running at http://localhost:3000/ and the client will be at http://localhost:5000/. The browser considers these two locations to be on different domains, similar to running the server on http://www.server.com and running the client on http://www.client.com. We will not be allowing external domains access to our cookies, so we have to find another alternative solution to using sessions.
If you're wondering why we won't be allowing access to our cookies, you should check out the articles on Cross-Origin Resource Sharing (CORS), and Cross-Site Request Forgery (CSRF) linked below. If you just want to start coding, check the boxes and move on.
"
Here I read all the materials recommended here, MDN documents about CORS and CSRF, but can't still understand reason I shouldn't use sessions if I use CORS and CSRF here.
I even found some pages saying that if I change the 'withCredentials' Field to be 'true', then I can adhere to sessions.(CORS requests with session/cookie)
session django-rest-framework cors
The question is just same as the title.
I was following a tutorial( from Thinkster ) about Django Rest Framework, one content about the authentications of which says like below.
"
In our case, the client and the server will be running at different locations. The server will be running at http://localhost:3000/ and the client will be at http://localhost:5000/. The browser considers these two locations to be on different domains, similar to running the server on http://www.server.com and running the client on http://www.client.com. We will not be allowing external domains access to our cookies, so we have to find another alternative solution to using sessions.
If you're wondering why we won't be allowing access to our cookies, you should check out the articles on Cross-Origin Resource Sharing (CORS), and Cross-Site Request Forgery (CSRF) linked below. If you just want to start coding, check the boxes and move on.
"
Here I read all the materials recommended here, MDN documents about CORS and CSRF, but can't still understand reason I shouldn't use sessions if I use CORS and CSRF here.
I even found some pages saying that if I change the 'withCredentials' Field to be 'true', then I can adhere to sessions.(CORS requests with session/cookie)
session django-rest-framework cors
session django-rest-framework cors
asked Jan 1 at 9:44
RheeRhee
1279
1279
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
First, you should understand how sessions and cookies work. When a request is made to site A, the browser sends all the cookies for that site along with the request which is used for session authentication.
Assuming an attacker Eve (popularly used in cyber security for some reason) having a site B wants to gain access to the site A, all he needs to do is just send a request while the browser adds A's cookies since the request is going to A. Voila! Your server authenticates the request and he has access. This type of attack is called Cross-Site Request Forgery (CSRF)
Now, here comes Cross-Origin Request Sharing (CORS). It is a mechanism used by browsers to prevent CSRF attacks. Before making such a request across domains , they first perfom a preflight request which basically asks the server if they accept requests from the given domain and which HTTP methods and headers they accept from such domain. If you don't have CORS setup in your server, (typically using django-cors), the browser will not allow cross domain requests by default.
Hence, you can actually use session authentication when your client and server are in different domains, but you have to ensure that only your client domain is whitelisted while requests from other domains are denied using the CORS configuration.
Of course a smarter and more evil Eve can still somehow find their way around this mechanism but it atleast ensures basic and minimum security for your site
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53994433%2fwhy-are-sessions-not-appropriate-for-cors%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
First, you should understand how sessions and cookies work. When a request is made to site A, the browser sends all the cookies for that site along with the request which is used for session authentication.
Assuming an attacker Eve (popularly used in cyber security for some reason) having a site B wants to gain access to the site A, all he needs to do is just send a request while the browser adds A's cookies since the request is going to A. Voila! Your server authenticates the request and he has access. This type of attack is called Cross-Site Request Forgery (CSRF)
Now, here comes Cross-Origin Request Sharing (CORS). It is a mechanism used by browsers to prevent CSRF attacks. Before making such a request across domains , they first perfom a preflight request which basically asks the server if they accept requests from the given domain and which HTTP methods and headers they accept from such domain. If you don't have CORS setup in your server, (typically using django-cors), the browser will not allow cross domain requests by default.
Hence, you can actually use session authentication when your client and server are in different domains, but you have to ensure that only your client domain is whitelisted while requests from other domains are denied using the CORS configuration.
Of course a smarter and more evil Eve can still somehow find their way around this mechanism but it atleast ensures basic and minimum security for your site
add a comment |
First, you should understand how sessions and cookies work. When a request is made to site A, the browser sends all the cookies for that site along with the request which is used for session authentication.
Assuming an attacker Eve (popularly used in cyber security for some reason) having a site B wants to gain access to the site A, all he needs to do is just send a request while the browser adds A's cookies since the request is going to A. Voila! Your server authenticates the request and he has access. This type of attack is called Cross-Site Request Forgery (CSRF)
Now, here comes Cross-Origin Request Sharing (CORS). It is a mechanism used by browsers to prevent CSRF attacks. Before making such a request across domains , they first perfom a preflight request which basically asks the server if they accept requests from the given domain and which HTTP methods and headers they accept from such domain. If you don't have CORS setup in your server, (typically using django-cors), the browser will not allow cross domain requests by default.
Hence, you can actually use session authentication when your client and server are in different domains, but you have to ensure that only your client domain is whitelisted while requests from other domains are denied using the CORS configuration.
Of course a smarter and more evil Eve can still somehow find their way around this mechanism but it atleast ensures basic and minimum security for your site
add a comment |
First, you should understand how sessions and cookies work. When a request is made to site A, the browser sends all the cookies for that site along with the request which is used for session authentication.
Assuming an attacker Eve (popularly used in cyber security for some reason) having a site B wants to gain access to the site A, all he needs to do is just send a request while the browser adds A's cookies since the request is going to A. Voila! Your server authenticates the request and he has access. This type of attack is called Cross-Site Request Forgery (CSRF)
Now, here comes Cross-Origin Request Sharing (CORS). It is a mechanism used by browsers to prevent CSRF attacks. Before making such a request across domains , they first perfom a preflight request which basically asks the server if they accept requests from the given domain and which HTTP methods and headers they accept from such domain. If you don't have CORS setup in your server, (typically using django-cors), the browser will not allow cross domain requests by default.
Hence, you can actually use session authentication when your client and server are in different domains, but you have to ensure that only your client domain is whitelisted while requests from other domains are denied using the CORS configuration.
Of course a smarter and more evil Eve can still somehow find their way around this mechanism but it atleast ensures basic and minimum security for your site
First, you should understand how sessions and cookies work. When a request is made to site A, the browser sends all the cookies for that site along with the request which is used for session authentication.
Assuming an attacker Eve (popularly used in cyber security for some reason) having a site B wants to gain access to the site A, all he needs to do is just send a request while the browser adds A's cookies since the request is going to A. Voila! Your server authenticates the request and he has access. This type of attack is called Cross-Site Request Forgery (CSRF)
Now, here comes Cross-Origin Request Sharing (CORS). It is a mechanism used by browsers to prevent CSRF attacks. Before making such a request across domains , they first perfom a preflight request which basically asks the server if they accept requests from the given domain and which HTTP methods and headers they accept from such domain. If you don't have CORS setup in your server, (typically using django-cors), the browser will not allow cross domain requests by default.
Hence, you can actually use session authentication when your client and server are in different domains, but you have to ensure that only your client domain is whitelisted while requests from other domains are denied using the CORS configuration.
Of course a smarter and more evil Eve can still somehow find their way around this mechanism but it atleast ensures basic and minimum security for your site
answered Jan 1 at 15:13
Ken4scholarsKen4scholars
1,4681716
1,4681716
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53994433%2fwhy-are-sessions-not-appropriate-for-cors%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown