Fix Security Misconfiguration in Ktor

Ktor's modularity is a double-edged sword. Out of the box, it lacks a 'secure by default' posture, leaving developers to manually wire security features. Common misconfigurations include permissive CORS policies, missing HSTS headers, and absent CSP, which expose your service to CSRF, XSS, and protocol downgrade attacks. Hardening the Ktor engine requires explicit configuration of the DefaultHeaders, HSTS, and CORS features.

The Vulnerable Pattern

fun Application.module() {
    install(CORS) {
        anyHost() // CRITICAL: Allows any origin to read response data
        allowMethod(HttpMethod.Options)
    }
    routing {
        get("/api/data") {
            call.respond(mapOf("status" to "exposed"))
        }
    }
}

The Secure Implementation

The hardened configuration addresses three major vectors. First, DefaultHeaders is used to inject 'nosniff' to prevent MIME-type sniffing and 'DENY' to stop clickjacking. Second, HSTS (HTTP Strict Transport Security) is enabled with a 1-year max-age to prevent SSL stripping attacks. Third, the CORS configuration is restricted to a specific trusted domain and HTTPS scheme, replacing the dangerous anyHost() wildcard. This ensures that sensitive data is only accessible to legitimate clients and protected during transit.

fun Application.module() {
    install(DefaultHeaders) {
        header("X-Content-Type-Options", "nosniff")
        header("X-Frame-Options", "DENY")
        header("Content-Security-Policy", "default-src 'self'")
    }
    install(HSTS) {
        maxAgeInSeconds = 31536000
        includeSubDomains = true
        preload = true
    }
    install(CORS) {
        allowHost("api.trusted-domain.com", schemes = listOf("https"))
        allowMethod(HttpMethod.Get)
        allowHeader(HttpHeaders.Authorization)
        allowCredentials = true
    }
}