Any remote interceptor connected to an interceptor server can apply mocks that change how the server handles requests. If the interceptor server is publicly available, intruders could use malicious interceptors to override the mocks and compromise the responses returned by the server. Although interceptors are meant to be used only in development, having a mock server in a staging or testing environment is a potencial use case.
Proposed solution
To better control which interceptors are allowed to apply mocks in a given interceptor server, we could add a new authentication API, allowing servers to validate interceptors before accepting their mocks.
Initially, we could have a form of API key authentication, where an interceptor server is initialized with a list of allowed keys. Valid interceptors would be created with those keys and pass them in all communication with the server. By default, no auth validation would be enabled.
Any remote interceptor connected to an interceptor server can apply mocks that change how the server handles requests. If the interceptor server is publicly available, intruders could use malicious interceptors to override the mocks and compromise the responses returned by the server. Although interceptors are meant to be used only in development, having a mock server in a staging or testing environment is a potencial use case.
Proposed solution
To better control which interceptors are allowed to apply mocks in a given interceptor server, we could add a new authentication API, allowing servers to validate interceptors before accepting their mocks.
Initially, we could have a form of API key authentication, where an interceptor server is initialized with a list of allowed keys. Valid interceptors would be created with those keys and pass them in all communication with the server. By default, no auth validation would be enabled.