CORS che accetta l'origine arbitraria con GET ma non con OPTIONS

Question

CORS che accetta l'origine arbitraria con GET ma non con OPTIONS

#1 da (0 voti)

1

Sto testando un'API, che consente un'origine arbitraria su POST / GET richieste, rispondendo con l'intestazione CORS Access-Control-Allow-Origin: * .

Tuttavia, con OPTIONS richieste e origine arbitraria, il servizio web non risponde con Access-Control-Allow-Origin: * , non usa affatto l'intestazione di risposta.

Questo significa che qualsiasi richiesta di verifica preliminare CORS con un'origine arbitraria fallirebbe.

Non vedo il punto di avere l'intestazione di risposta CORS per GET / POST richieste, ma non la richiesta OPTIONS . Tuttavia, non posso fornire un esempio di vulnerabilità o di come questo possa essere sfruttato.

Q: È sicuro dire che non pone una vulnerabilità, ma è solo una cattiva pratica?

api web-application cors web-service

posta Dolores The Third 03.12.2018 - 13:45

fonte

1 risposta

Leggi altre domande sui tag api web-application cors web-service

Identificazione e comprensione di un protocollo di votazione crittografico Oauth2 PKCE - Si può fidare del refresh_token?

score 0 · Answer 1

Q: Is it safe to say that does not pose a vulnerability, but is just bad practice?

Poiché si tratta di un'API e supponendo richiede Authorization di intestazione per tutte le richieste, è sicuro che non rappresenta una vulnerabilità. Il comportamento, tuttavia, limita la comunicazione allo stesso dominio.

Vale la pena notare che non tutte le richieste sono preflight. Per ulteriori dettagli, fai riferimento al link .

Un'API si aspetta, se configurata correttamente , un'intestazione Content-type corretta e un'intestazione di autorizzazione che nella maggior parte dei casi è Authorization . Se una richiesta imposta un " nome dell'intestazione proibito " o un% non sicuro% co_de, è sempre sottoposto a preflight. E come tale, nessun altro dominio sarebbe in grado di inviare una richiesta autenticata.