We're hosting an ASP.Net Razor Pages app (.Net 7.0) using an IIS 10 webserver. The app itself works fine. Now, one of our customers decided they want to use the app on their own website, embedding it in an iframe. So that's where CORS comes into play.
When activating CORS support in the app's middleware for whatsoever reason didn't work, we decided to go the IIS-way, using the CorsModule instead. By now, the website at least gets displayed within the iframe of the testing website, which means that a couple of GET requests work just fine.
However, when I try to login via login form, I receive a "400 Bad Request" for the POST request. Even after reading several official documentations and guides on how to enable CORS with and without credentials, I have no idea what I am missing here.
400 Bad Request on login POST request
The configuration of the IIS CorsModule reads as follows:
Config Editor test site overview
Config Editor test site allowHeaders
Config Editor test site allowMethods
Additionally, I set up two custom headers for Content-Security-Policy as I read that CSP is supposed to have replaced Access-Control-Allow-Headers. This is what finally at least made the displaying of the website within the iframe work:
We've already been spending a couple of days with this issue and appreciate any help provided!
EDIT for additional information:
@Heiko Theißen:
Sorry, my response would've been too long for a comment, so I'm replying here:
As far as I know, iframes come with additional restrictions in combination with CORS, especially when talking about login functionality/credentials. But you're right, right now I don't get any obviously CORS-related error messages (which I did earlier, but they're gone now). Still, the login works fine on the website itself, so my guess was that the failure is CORS-with-credentials-related.
The request looks as follows:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: de,en-US;q=0.7,en;q=0.3
Connection: keep-alive
Content-Length: 244
Content-Type: application/x-www-form-urlencoded
DNT: 1
Host: ***.de
Origin: ***.de (<-- same as "Host")
Referer: ***.de (<-- same as "Host")
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
TE: trailers
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
The server response is this:
content-security-policy: frame-ancestors 'self' *.de ..de *.de ..de;
date: Fri, 17 Mar 2023 08:05:47 GMT
server: Microsoft-IIS/10.0
strict-transport-security: max-age=2592000
vary: Origin
x-content-security-policy: frame-ancestors 'self' *.de ..de *.de ..de;
X-Firefox-Spdy: h2
Additionally, Firefox then let's me know the request failed with a 400 error which looks like this:
Status: 400 Bad Request
Version: HTTP/2
Übertragen: 1,32 kB (0 B Größe)
Referrer Policy: strict-origin-when-cross-origin
The payload should be pretty much only the login data, although I'm not sure how to verify that. After the successful login, the user is supposed to be redirected to another resource of that website. And of course, with all this there come the usual ASP.Net cookies etc. into the game, AntiForgery-Cookies and stuff. Maybe there is something going wrong in that direction...
Nothing CORS-related here.
The Content-Security-Policy: frame-ancestors header in the response may prevent the page from appearing in an iframe (but you redacted the details, therefore I cannot tell for sure). If this is the case, there is no chance to
use the app on their own website, embedding it in an iframe.
This is because the page does not want to appear in an iframe (perhaps in order to prevent clickjacking).
There is another thing that can go wrong: The cookies that the embedded page wants to set after successful logon may be blocked because they come from a different site or domain than the embedding page. Things to check are the samesite settings of the cookies and whether the browser blocks them as third-party-cookies.
To summarize: It is an audacious undertaking to display a website inside the iframe of another website. It will likely fail unless both websites are developed in close collaboration.
