Need

Restriction of cross-origin access to explicitly trusted origins

Context

Description

import io.ktor.http.HttpHeaders
import io.ktor.server.application.Application
import io.ktor.server.application.install
import io.ktor.server.plugins.cors.routing.CORS

fun Application.configureCors() {
    install(CORS) {
        // Every website can call the API with the user's credentials...

The `configureCors` function below installs the Ktor `CORS` plugin with `anyHost()`, allows credentials and accepts the `Authorization` header. `anyHost()` makes the server answer cross-origin requests from every website. Combined with `allowCredentials = true`, the plugin reflects the origin of each request, so a script on any page visited by a logged-in user can call the API with that user's cookies and read the responses: profile data, tokens or business records. The attacker only needs the user to open a malicious page. Setting `Access-Control-Allow-Origin` to `*`, or to the value of the request `Origin` header without validation, has the same effect in servlet-based applications.

import io.ktor.http.HttpHeaders
import io.ktor.http.HttpMethod
import io.ktor.server.application.Application
import io.ktor.server.application.install
import io.ktor.server.plugins.cors.routing.CORS

fun Application.configureCors() {
    install(CORS) {...

The corrected configuration replaces `anyHost()` with `allowHost`, listing the only front end origin allowed to call the API, and restricts it to the `https` scheme. Requests from any other origin receive no CORS headers, so the browser prevents the calling script from reading the response. Credentials remain allowed only because the origin is explicit, and the plugin only accepts the methods and headers the front end uses. When several origins are needed, each one should be listed with its own `allowHost` call. Pattern checks such as "ends with example.com" must be avoided, because `evil-example.com` also satisfies them.

References