About Firewall Access
The following Anypoint Platform browser tools route calls to your API through a reverse proxy by default:
-
API Console
-
API Designer
-
API Notebook
The browser can then get resources from your API and Anypoint Platform browser tools undeterred by the same-origin restriction policy.
When a browser makes an HTTP request to a domain and that domain returns a page, that page is the origin domain. Any scripts running in that page are allowed to make additional requests back to the origin domain only. If a script attempts to make a request to, or load resources from a different domain, the response is normally blocked to prevent the script from gaining access to other sites you visited.
If your API is located behind a firewall that prevents inbound requests, the API is unreachable. You won’t be able to use API Console, API Designer, or API Notebook unless you use the Anypoint Platform Cross-Origin Resource Sharing (CORS) policy to allow users and/or client requests to access the tools whose resources are located outside your origin domain.
Alternatively, for testing purposes, you can use one of the following ways to avoid same-origin restriction:
-
Bypass the proxy
-
Disable same-origin restrictions in your browser.
Releasing an API to production without properly addressing a security model to handle cross-origin resources can potentially enable dangerous Cross-Site Request Forgery (CSRF) attacks, among other threats that can harm clients and users accessing your resources.
If you set up an API proxy, you need to implement and apply a CORS Policy for your browser to be able to load the resources in the API behind your firewall and the Anypoint Platform’s browser tools.
If you are testing your implementations in a local, or test environment, you can disable same-origin restrictions in your browser to access the online browser tools provided by Anypoint Platform.
Do not use disable same-origin restrictions in your browser for a production release of your implementation.
Disabling Mixed Content Blocking
When an HTTPS web page retrieves resources from an unsecured HTTP endpoint, the resulting blend of secure and unsecure content is called mixed content. Browsers block such mixed content and display an error because of the security implications. For example, mixed content introduces the possibility that a man-in-the-middle attacker could have injected malicious site resources (such as scripts) during the request and response. You may encounter this issue when using the API Manager, and it’s important to understand how you can mitigate it.
The API Manager browser tools (API Console, API Designer, and API Notebook) are hosted on an HTTPS endpoint. All requests and responses sent between your browser and the platform’s servers are encrypted using SSL. In addition, if you’re using the default server-side proxy generated by the tools instead of bypassing the proxy, the proxy makes requests to your API and encrypts the responses through SSL so that they can be displayed in the browser without triggering a mixed content error.
If you’ve disabled the platform’s server-side proxy, any requests to your API are no longer routed through this proxy and are instead made directly to it. This situation isn’t a problem if your API resides at an HTTPS endpoint, because all communication between the browser and the requested resources is encrypted using SSL. However, if your API has an HTTP endpoint, the API Manager browser tools makes requests to the unsecured HTTP endpoint and your browser blocks the resulting "mixed content" — a mix of the browser tool’s HTTPS (secured) content and your API’s HTTP (unsecured) content.