CORS and IP restrictions
Two controls that are often confused. Neither one proves who is calling.
| CORS | IP allowlist | |
|---|---|---|
| Enforced by | The browser | The MyTPE server |
| Decides | Which websites may read a response in a browser | Which source addresses may use an integration |
| Applies to | Browsers only | Every request of that integration |
| Stops a script on a server | No | Yes, unless it runs from an allowed address |
| Proves who is calling | No | No |
CORS
CORS tells a browser which websites may read a response. It doesn't stop any other kind of client, so it isn't authentication.
/api/ext and /oauth/token send no CORS headers, so a browser can't read their responses. That's
deliberate: these endpoints are for servers. The MyTPE dashboard's own API allows exact, listed
origins only.
IP allowlists
An allowlist limits the addresses that can use one integration. If a secret leaks, an attacker outside your ranges can't use it.
An allowlist doesn't:
- Stop someone who can send requests from one of your addresses.
- Replace credentials, scopes or account checks. They always apply.
- Make a stolen secret safe. Rotate a leaked secret even if you have an allowlist.
How MyTPE determines the source address
MyTPE reads the address of the connection. It reads a forwarded-address header only from proxies it's configured to trust, so a client can't claim an address by sending that header itself. If MyTPE can't establish the address, an integration with an allowlist is refused.
To set one up, see Restrict an integration by IP address.