Cross-origin access (CORS)

Allow a particular browser origin to read an application response. Cross-origin resource sharing (CORS) grants that browser permission; it does not authenticate callers or prevent non-browser requests.

An origin consists of scheme, host and port. A project path is not part of it: all pages under https://f5-sales-demo.github.io share that origin, including this guide.

Visitor response: The allowed documentation origin can read the synthetic response.

Same-origin and cross-origin access

Request context	Browser behavior
Application panel fetching its own origin	Same-origin access works without CORS permission.
Documentation widget fetching the application	Cross-origin access requires permission for https://f5-sales-demo.github.io.
A different cross-origin page	The browser cannot expose the response unless that origin is allowed.

Navigating directly to an echo address is not a CORS test. It does not test whether a page on another origin can read the response. The application panel shares the application’s origin, so its own fetch also does not demonstrate denied cross-origin access.

Route permission and preflight

The /demo/cors route allows GET, POST and OPTIONS, with Content-Type and X-CR-Client request headers. Credentials are disabled. A POST with these headers requires a browser preflight before the application request. The root route grants no CORS access.

{
  "spec": {
    "routes": [
      {
        "simple_route": {
          "path": {
            "path": "/demo/cors"
          },
          "http_method": "ANY",
          "origin_pools": [
            {
              "pool": {
                "name": "<ORIGIN_POOL_NAME>",
                "namespace": "<XC_NAMESPACE>"
              },
              "weight": 1,
              "priority": 1
            }
          ],
          "advanced_options": {
            "priority": "DEFAULT",
            "cors_policy": {
              "allow_origin": [
                "https://f5-sales-demo.github.io"
              ],
              "allow_methods": "GET, POST, OPTIONS",
              "allow_headers": "Content-Type, X-CR-Client",
              "expose_headers": "X-Response-Owner",
              "allow_credentials": false,
              "maximum_age": 0
            }
          }
        }
      }
    ]
  }
}

Read the allowed response

The focused widget below sends one synthetic POST only when clicked. It reserves two requests for the preflight and POST, within a twelve-request page budget.

1. Select Test allowed cross-origin access.
2. Inspect the returned status and synthetic echo; the widget can read the body from the application origin.
3. In the browser’s network inspector, inspect the preflight and POST response permissions.

Expected result: The response grants the exact documentation origin with Access-Control-Allow-Origin. The preflight advertises the configured methods and headers. A denied origin receives no browser permission. A fetch failure alone cannot distinguish CORS denial from connectivity or server failure; it means the test did not complete.

Verified endpoint: Open the CORS echo. This navigation shows the endpoint, not cross-origin permission. Use Rate limits for the separate request-limit demonstration.