I was going through official documentation to enforce HTTPS in ASP.NET Core. There I found a warning -
Do not use RequireHttpsAttribute on Web APIs that receive sensitive
information. RequireHttpsAttribute uses HTTP status codes to redirect
browsers from HTTP to HTTPS. API clients may not understand or obey
redirects from HTTP to HTTPS. Such clients may send information over
HTTP. Web APIs should either:
Not listen on HTTP.
Close the connection with status code 400 (Bad Request) and not serve the request.
What I know about [RequireHttps] attribute is It set 302 Found code and a redirect url. something like this -
GET http://api.example.com/values
302 Found
Location: https://api.example.com/values
On the other hand, official documentation recommends to use -
HTTPS Redirection Middleware (UseHttpsRedirection) to redirect HTTP
requests to HTTPS.
Uses the default HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
What I understood from this, it also redirects HTTP to HTTPS, with different status code 307.
To me they are doing similar thing. I don't clearly understand what benefit I am getting using HTTPS Redirection Middleware (UseHttpsRedirection) over RequireHttps Attribute. What I am missing here ?
I was going through official documentation to enforce HTTPS in ASP.NET Core.
What I know about [RequireHttps] attribute is It set 302 Found code and a redirect url.
On the other hand, official documentation recommends to use HTTPS Redirection Middleware (UseHttpsRedirection)
To me they are doing similar thing.
I suppose that the information you mentioned is from this official doc about "Enforce HTTPS in ASP.NET Core".
As we know, for Web APIs scenario, API client (consumer/caller App) could be not browser client, which would not understand or obey redirection from HTTP to HTTPS via HTTP status codes. We should avoid our API endpoint response client with redirection status codes, so as warning part suggested "Do not use RequireHttpsAttribute on Web APIs that receive sensitive information".
And in warning part it also shows two approaches to reject insecure HTTP requests for Web APIs: 1) not expose HTTP endpoints; 2) return an error code. In my view, talking about "reject insecure HTTP requests for Web APIs scenario" is over here.
Besides, we should note that topic of this doc is about redirecting HTTP requests to HTTPS in ASP.NET Core, RequireHttpsAttribute could be applied to specific controller/action(s), to enforce HTTPS for entire ASP.NET Core web apps, using HTTPS Redirection Middleware is recommended (not mean that we should use this Middleware to reject insecure HTTP requests for Web APIs).
Related
How can I redirect client HTTP requests to HTTPS when using Apache APISIX? Is there a more convenient way? How does it work?
This is a built-in feature provided by Apache APISIX. You can learn it from the redirect plugin, see https://apisix.apache.org/docs/apisix/plugins/redirect/ for more details.
The related field is http_to_https.
I am working on a web application that is hosted in the internet, but shall be able to use a REST API provided by a local HTTP-printserver.
The problem is, that when the application is accessed via HTTPS, all my XmlHttpRequest to the local HTTP-printserver are blocked (because of security mechanisms of the browser).
Therefore my "solution" is to use plain HTTP for the web application.
However, whenever I open the site in my browser - explicitly with http (e.g. http://mysite.de/app/index.html) the browser sends an "Upgrade-Insecure-Requests" which is accepted by the webserver and they switch over to HTTPS.
Is there a way how to deny/reject the upgrade to HTTPS?
Ideally by .htaccess
Ideally only for index.html in the app folder
We have web site and API and their URL as http://example.com/?api=xxxxxxxxx
suppose we apply https on our domain and server then it would effect our existing web sites and API and can both protocol can work.
Yes, switching to HTTPS may potentially affect your existing API customers. However, it depends on:
Whether you'll force HTTPS or not
How developers interacts with your API
If you force HTTPS, you'll likely setup a redirect from HTTP to HTTPS. If the clients are not designed to follow redirects (in general simple clients are not), then your customers will start noticing 301 or 302 redirect status codes rather than 200.
In this case, the option could be to add HTTPS and deprecate HTTP. Keep HTTP and HTTPS in parallels for a while, long enough to inform your customers to move to the HTTPS version.
I am setting up a RESTful API server, and we are requiring clients to use HTTPS. Is it best to set this up to completely block port 80 and return a 'not found' for requests to HTTP, or should I redirect all of these requests to HTTPS? Normally I setup my web servers to do this, but my concern is how well clients will handle the 302 Redirect in their RESTful calls. Is there a best practice or recommended way to handle this?
Thanks!
A common approach here is to respond with status code 403 Forbidden and to specify in the response body that a secure connection is required.
Is there anything wrong with configuring a webserver to map SSL traffic (port 443) to the same document root as normal traffic (port 80)?
Using the same document root for both http and https means you need to implement the following:
On each page that needs to be secure, there needs to be some application code that redirects the user to the https version if they somehow got to the http version (or to rediect the user to the login page if they have no session).
The login page always needs to redirect to the https version.
For pages that are accessible via both http and https, you need to set a canonical URL to ensure it doesn't appear like you have duplicate content.
Is there a better way to configure encryption of user account pages? Is there a best practice to separate website into HTTP and HTTPS sections?
It's not necessarily wrong to do this, but as your points 1..3 show, it introduces complications. It seems to me that setting up a separate document root might be a lot simpler than working around the complications.
In Internet Information Server 7.X you can define a "secure path" which is require to access with HTTPS and you can redirect the user to a user-friendly error page.
Maybe this can be a good solution to mix the document root and keep parts of the application secured.
Redirecting http automatically to https allows for man-in-the-middle attacks and is therefore not recommended. A man-in-the-middle could manipulate your HTTP traffic to send you to a malicious HTTPS site that resembles your HTTPS content.