1. Introdução

A evolução das aplicações web nas últimas décadas alterou profundamente a forma como sistemas distribuem funcionalidades, processam dados e interagem entre si. Em arquiteturas antigas, predominantemente monolíticas, toda a aplicação operava sob uma única origem e havia pouca necessidade de comunicação com domínios externos. Com a adoção de arquiteturas distribuídas, como microsserviços, serviços em nuvem, CDNs, provedores de identidade e aplicações de página única (SPAs), tornou-se comum que sistemas modernos realizem comunicações entre diferentes origens para cumprir fluxos essenciais.

A ampliação dessas integrações aumentou também a relevância dos mecanismos de isolamento implementados pelos navegadores. Entre eles, destaca-se a Same-Origin Policy (SOP), principal barreira de proteção da Web, responsável por impedir que scripts executados em um domínio acessem livremente dados provenientes de outro domínio.

Com a crescente necessidade de comunicação legítima entre origens distintas, a SOP tornou-se insuficiente para atender às demandas das aplicações modernas. Esse cenário motivou a padronização do mecanismo Cross-Origin Resource Sharing (CORS), criado para flexibilizar de forma segura o isolamento entre origens, permitindo que servidores declarem explicitamente quais domínios externos estão autorizados a solicitar e ler seus recursos através de código Javascript.

2. Protocolo HTTP

O HTTP 1.1 é definido no documento RFC 2616 como um protocolo de comunicação textual a nível de aplicação utilizado em sistemas de informação distribuídos, e é a base de praticamente toda a comunicação que ocorre na web. É usado não apenas para o carregamento de páginas e recursos estáticos (como imagens, CSS e JavaScript), mas também para APIs, aplicações web modernas, serviços móveis, integrações entre sistemas e até comunicações em IoT (Internet das Coisas).

Um dos aspectos fundamentais do HTTP é o fato de ser um protocolo stateless (sem estado), o que significa que cada requisição é tratada de forma independente, sem que o servidor mantenha informações sobre interações anteriores com o mesmo cliente. Essa escolha de design não foi um descuido, mas sim uma decisão arquitetural consciente, ligada ao contexto tecnológico da década de 1990.

Naquele período, a internet ainda era incipiente, e a World Wide Web, idealizada por Tim Berners-Lee, tinha como principal objetivo permitir o compartilhamento simples de documentos de hipertexto. As máquinas possuíam recursos limitados, o que tornava inviável a manutenção de estados persistentes entre cliente e servidor. Dessa forma, manter o protocolo leve, simples e independente de sessão era fundamental para garantir que qualquer computador pudesse se comunicar com qualquer outro, em qualquer parte do mundo.

Essa filosofia de simplicidade e interoperabilidade entre diferentes sistemas é reforçada por Roy Thomas Fielding, um dos principais autores das especificações do HTTP e criador da arquitetura REST (Representational State Transfer). Em sua tese de doutorado, Fielding explica que a ausência de estado induz as propriedades de visibilidade, escalabilidade e confiabilidade.

Em termos mais amplos, a visibilidade é aprimorada porque um sistema de monitoramento consegue compreender completamente o que está acontecendo apenas analisando uma única requisição, sem precisar consultar informações de interações anteriores. A confiabilidade aumenta porque, em caso de falhas parciais, como a interrupção de uma conexão ou a queda de um servidor, a recuperação é mais simples, já que o servidor não precisa restaurar ou manter o estado de sessões anteriores para continuar operando. Por fim, a escalabilidade é favorecida porque o servidor não precisa reservar recursos para armazenar informações de cada cliente entre as requisições; assim, após atender uma solicitação, ele pode liberar imediatamente seus recursos, permitindo lidar com um número muito maior de conexões simultâneas.

2.1 Funcionamento do HTTP

O HTTP funciona no modelo de requisição e resposta, no qual o navegador (cliente) envia uma mensagem solicitando um recurso, e o servidor responde com outra mensagem contendo o resultado do pedido. Esse ciclo ocorre em milissegundos e se repete diversas vezes durante o carregamento de uma página.

Uma requisição web inicia-se com a resolução de nomes via DNS (Domain Name System), mecanismo responsável por traduzir o domínio alfanumérico no endereço IP do servidor de destino. Com o endereço IP obtido, o cliente inicia uma conexão na camada de transporte via protocolo TCP (Transmission Control Protocol) através de um socket. Uma vez consolidado o canal de comunicação, a mensagem estruturada sob o protocolo HTTP é transmitida ao servidor. Por fim, o servidor e/ou a aplicação exposta faz o parsing do conteúdo HTTP, interpreta, e devolve a resposta ao cliente.

2.2 Requisição HTTP para um login

Uma requisição HTTP é formada pela linha de requisição(Verbo HTTP + Caminho + Versão do HTTP), pelos cabeçalhos (headers) e, opcionalmente, por um corpo (body). Os verbos HTTP indicam uma ação que queremos realizar no servidor. Os verbos são: GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE e CONNECT a partir da definição do HTTP 1.1.

Descrição dos principais campos:

• POST — método HTTP usado para enviar/armazenar dados no servidor.
• /api/login — recurso ao qual o cliente está enviando a requisição
• Host — identifica o domínio do servidor (Vhost) que deve processar o pedido.
• User-Agent — identifica o navegador e o sistema operacional do cliente.
• Content-Length — informa o tamanho do corpo da requisição em bytes.
• Referer — indica a URL da qual o usuário ou script navegou para a página atual.
• {...} - Dados enviados em formato JSON no corpo da requisição.

Quando o usuário insere suas credenciais em um formulário de login e clica em “Entrar”, o navegador envia uma requisição HTTP ao servidor, geralmente utilizando o método POST. Essa requisição contém, no corpo (body), os dados de autenticação em formato JSON, nesse caso, o nome de usuário e a senha.

O servidor, ao receber essa requisição, interpreta os dados, valida as credenciais no banco de dados e, se estiverem corretas, inicia uma nova sessão para o usuário autenticado. Durante esse processo, a lógica no lado do servidor(PHP, Node, Python, etc.) gera um cookie com um identificador único, e o servidor o associa a uma sessão de usuário. Uma sessão é um contexto mantido no servidor e identificado por um token único (neste caso, o cookie), que permite ao servidor recuperar os dados associados àquele usuário específico, possibilitando ações personalizadas, controle de acesso e persistência de estado entre diferentes interações.

O cookie é então enviado de volta ao cliente por meio do cabeçalho Set-Cookie, que permite que o navegador armazene o valor do cookie no seu banco de dados. Assim, o servidor “reconhece” o usuário em requisições subsequentes ao associar o valor do cookie que o navegador envia à sessão correspondente armazenada no servidor.

Os status codes indicam o resultado de uma requisição HTTP e são divididos em cinco categorias

• 1XX - Respostas informativas
• 2XX - Sucesso
• 3XX - Redirecionamentos
• 4XX - Erros do cliente
• 5XX - Erros do servidor

3. Origem

O conceito de origem(origin) é um dos fundamentos mais importantes do modelo de segurança da Web moderna. Ele define o contexto de confiança que determina quais recursos podem interagir entre si dentro de um navegador. Toda página, script, cookie, requisição ou objeto carregado pelo navegador é associado a uma origem específica, e essa associação é o que permite a aplicação da Política de Mesma Origem (Same-Origin Policy), a principal barreira de isolamento entre sites.

De maneira formal, a origem é composta pela combinação de três elementos: o esquema (scheme), o domínio(host) e a porta (port). Duas URLs são consideradas da mesma origem se, e somente se, esses três componentes coincidirem exatamente.

Essa distinção é essencial para a proteção dos usuários, pois impede que scripts executados a partir de uma origem acessem ou modifiquem livremente recursos de outras origens. Sem a definição clara de origem, uma página maliciosa poderia ler dados sensíveis retornados por uma requisição autenticada em outro domínio, resultando em roubo de informações, sequestro de sessão ou ações não autorizadas em nome do usuário.

4. Same-Origin Policy

A Same-Origin Policy (SOP), ou Política de Mesma Origem, é um dos princípios fundamentais da segurança na Web. Ela foi criada para impedir que scripts ou documentos de uma origem interajam livremente com recursos de outra origem, garantindo isolamento entre sites diferentes e protegendo dados sensíveis dos usuários. Na prática, isso significa que uma página carregada de uma determinada origem, definida pela combinação de esquema (protocolo), domínio e porta só pode acessar dados provenientes dessa mesma origem. Para entender esse conceito, visualizações são de grande ajuda. Elas permitem compreender como o navegador delimita os contextos de execução e restringe a comunicação entre eles.

Quais são as possibilidades de interação de um script carregado em "http://www.exemplo.com" ?

A SOP, portanto, utiliza a definição de origem para determinar quais recursos e dados um documento ou script podem acessar dentro do navegador, delimitando rigorosamente o escopo de interação entre páginas. Isso significa que, ao carregar um site, o navegador cria um sandbox próprio para aquela origem, e tudo o que pertence a ela, como cookies, localStorage, respostas de requisições e variáveis JavaScript permanece isolado das demais origens.

5. Cookies

Cookies são pequenos arquivos de texto que os sites armazenam no navegador do usuário com o objetivo de registrar informações sobre a sua interação com a aplicação web. Eles funcionam como uma memória que permite que o servidor “reconheça” o usuário em visitas futuras, mesmo em um protocolo como o HTTP, que é naturalmente sem estado.

Cada cookie contém um conjunto de pares chave–valor, que podem incluir dados como identificadores de sessão, preferências de idioma, itens de um carrinho de compras ou credenciais temporárias de autenticação. Quando o usuário acessa novamente o mesmo domínio, o navegador envia automaticamente os cookies correspondentes ao servidor, possibilitando a continuidade da sessão ou a personalização da experiência.

Existem diferentes tipos de cookies quanto à sua finalidade e duração. Os cookies de sessão são temporários e são apagados ao fechar o navegador, enquanto os cookies persistentes permanecem armazenados por um período determinado pelo servidor. Também há distinção entre cookies próprios (gerados pelo domínio visitado) e cookies de terceiros, geralmente associados a conteúdos incorporados de outros domínios, como anúncios, widgets e rastreadores.

Do ponto de vista de segurança e privacidade, os cookies podem representar riscos se forem mal configurados. Por exemplo, um cookie de sessão que não estiver protegido por HTTPS pode ser capturado por um invasor em um ataque MITM, permitindo o sequestro de sessão. Para mitigar esse tipo de problema, existem flags (atributos) de cookies, que definem como os cookies devem ser tratados pelo navegador.

Entender o que são os cookies, e como o navegador os utiliza, é de suma importância para o entendimento dos casos onde o CORS é usado em requisições que transmitem credenciais.

5.1 Atributos de cookies

Como os cookies podem conter dados sensíveis, como identificadores de sessão, o protocolo HTTP define um conjunto de flags (atributos) que controlam o comportamento, escopo e o nível de segurança desses cookies. Esses atributos são enviados pelo servidor no cabeçalho Set-Cookie, e o navegador os aplica ao armazenar o cookie localmente.

A seguir, são apresentadas as principais flags e seus significados:

• Secure - Garante que o cookie só será transmitido por conexões HTTPS. Isso impede que o valor do cookie trafegue em texto puro pela rede, reduzindo o risco de interceptação.
• HttpOnly - Impede o acesso ao cookie por código javascript. Cookies com HttpOnly não podem ser lidos via document.cookie, tornando ataques de Cross-site Scripting incapazes de exfiltrar esses cookies.
• Samesite - Controla o envio do cookie em contextos cross-site(entre sites). É uma das principais defesas contra Ataques Cross-Site Request Forgery (CSRF).
  
  Pode receber 3 valores:
  
  

  Lax - Valor padrão nos navegadores modernos. Permite envio em navegações de nível superior iniciadas pelo usuário (como cliques). Ou seja, os cookies serão enviados em Requisições GET padrões entre domínios

  Strict O cookie só é enviado se a navegação ocorrer dentro da mesma origem. A interação a partir de outros domínios não envia o cookie.

  None Desativa restrições, permitindo envio em qualquer contexto, mas exige obrigatoriamente o uso da Flag Secure.

• Domain - Define para qual domínio o cookie será enviado.Quando ausente, o cookie fica restrito ao domínio exato que o criou. Quando especificado,passa a ser acessível também por subdomínios, ampliando o escopo de exposição.
• Path - Determina o caminho da URL no qual o cookie será incluído. Permite limitar o cookie a rotas específicas, reduzindo a exposição desnecessária.
• Expires/Max-Age - Controlam a duração do cookie.
  
  

  Expires Define data e horário exatos da expiração do cookie

  Max-Age Define tempo em segundos para expiração do cookie

6. Cross-Origin Resource Sharing

Segundo definições do MDN Web Docs, o Cross-Origin Resource Sharing (CORS) é um mecanismo que utiliza cabeçalhos HTTP para informar aos navegadores se uma requisição cross-origin(entre origens) pode ser realizada. Ou seja, é o CORS que define se código javascript executado a partir de uma origem "A" pode acessar a resposta de uma requisição feita a uma aplicação exposta em uma origem "B". Portando, pode-se dizer que o CORS é responsável por flexibilizar restrições impostas pela Same-Origin Policy.

O controle de acesso via CORS é de responsabilidade do desenvolvedor. A configuração deve ser feita no lado do servidor, especificando quais origens, métodos e headers são permitidos para endpoints(caminhos) específicos. Isso normalmente é feito através de um middleware.

A imagem acima mostra uma configuração de CORS feita em uma aplicação Node.js usando o framework Express. Note que o objeto Javascript "allowedConfig" define as origens("https://dominio.com" e "https://porta.dominio.com"). Também nota-se opções relacionadas a métodos, headers, e credenciais. Isso também é importante, mas será discutido mais adiante.

Abaixo da configuração definiu-se a rota "/user/profile" (acessível via Verbo HTTP GET) e aplicou-se um middleware(cors(allowedConfig))que reforça que o controle de CORS é necessário para essa rota. Isso significa que toda requisição a esse caminho, partindo de outro domínio, será submetido à configuração de CORS definida pelo desenvolvedor. Outra forma de se aplicar o CORS seria utilizando um middleware global (funcionaria para todas as rotas), no entanto escolhi aplicar apenas no caminho "/user/profile" para evidenciar que o CORS é flexível no sentido que pode ser usado em caminhos específicos.

Acredito que a melhor forma de entender o CORS é explicando como esse código é aplicado na prática. Dito isso, preste bastante atenção no exemplo a seguir:

• 1 - Imagine que o código da imagem acima está em uma aplicação exposta na internet no domínio "meusite.com".
• 2 - Código javascript no domínio "sitedaora.com" tenta interagir com o endpoint "meusite.com/user/profile", que retorna dados em formato JSON fixos (por conveniência).
• 3 - O código da imagem define explicitamente as origens cujo código Javascript pode ler e manipular essa resposta JSON.
• 4 - "sitedaora.com" não está entre os domínios permitidos fixados no array --> dominio.com e portadominio.com.
• 5 - O navegador lê os cabeçalhos(headers) devolvidos na resposta HTTP do servidor, e aplica a política do CORS que foi definida na configuração.
• 6 - Script em "sitedaora.com" não consegue ler a resposta pelos seguintes motivos:
• 7 - O navegador impede a leitura (requisições "simples") OU a requisição é "dropada" antes de chegar ao servidor(requisição "complexa" --> falha na requisição preflight).

Aprofundaremos nos assuntos de cabeçalhos cors, requisições(simples e complexas) mais adiante.

Você pode estar se perguntando: Mas como isso pode ser perigoso para um usuário comum?

Em aplicações que utilizam autenticação baseada em cookies, a leitura de respostas autenticadas no contexto da vítima por um domínio malicioso torna-se viável caso as flags dos cookies (como SameSite) e a política de CORS tenham certas configurações:

1 - Cookie de sessão com flags: "SameSite: none" e "Secure"

2- Se o CORS da aplicação vítima tiver configurações permissivas para as origens e devolver o domínio malicioso no header "Access-Control-Allow-Origin" durante a resposta.

3- O header "Access-Control-Allow-Credentials com configuração "true", que permite a leitura de respostas em para requisições feitas com uso de cookies(autenticadas). Dessa maneira, código javascript malicioso hospedado no domínio de um atacante pode receber a resposta dessas requisições e obter dados sensíveis de vítimas.

Agora preste atenção em outra situação que demonstra isso:

• 1 - Um agente malicioso estuda uma aplicação que quer atacar, e entende quais requisições são feitas.
• 2 - A aplicação alvo é encontrada na internet através do domínio "sitealvo.com".
• 3 - O atacante identifica um endpoint GET que o interessa.
• 4 - O endpoint GET https://sitealvo.com/api/data/card devolve dados JSON de cartão de crédito que um usuário salvou ao criar a conta no site.
• 5 - O atacante identifica que o mecanismo de autenticação da aplicação é baseado em cookies. A configuração do cookie de sessão tem a flag Secure habilitada, e a flag Samesite está configurada com o valor none.
• 6 - Usando o Proxy Burpsuite, o atacante altera o cabeçalho "Origin" especificando um valor qualquer, e o servidor reflete o mesmo valor ao devolver o cabeçalho "Access-Control-Allow-Origin" na resposta". Isso significa que o CORS está permissivo para todas as origens.
• 7 - O atacante observa que a resposta também devolve o cabeçalho "Access-Control-Allow-Credentials" com o valor "true".
• 8 - Todas essas condições juntas resultam em um endpoint que está vulnerável a um ataque que explore essa configuração permissiva.
• 9 - Através de uma aplicação própria, que roda em um domínio "malicioso.com", o atacante insere código javascript que faz uma requisição para "sitealvo.com/api/data/card".
• 10 - O atacante faz uso de APIs disponíveis no ambiente de runtime dos browsers (fetch ou ajax) para criar esse código javascript
• 11 - O atacante insere esse script que carrega automaticamente ao acessar "https://malicioso.com/"
• 12 - Qualquer pessoa que estiver logada e com uma sessão ativa em "sitealvo.com", e visitar "malicioso.com" terão seus dados de cartão de créditos vazados para o atacante
• 13 - E isso acontece justamente pelo fato de que o CORS em "sitealvo.com" está excessivamente permissivo, e permite que o código javascript hospeado em qualquer domínio faça requisições autenticadas em nome dos usuários da aplicação!

6.1 Requisição Preflight

A Requisição Preflight consiste em uma requisição HTTP utilizando o método OPTIONS, enviada pelo navegador antes de requisições consideradas potencialmente sensíveis pelo mecanismo de CORS. Em particular, o preflight ocorre sempre que a requisição original utilizar métodos diferentes de GET, ou POST com tipos MIME não simples. Após receber a resposta do servidor, o navegador avalia os cabeçalhos retornados e determina se a requisição original está autorizada a prosseguir.

Esse comportamento é essencial para que o navegador verifique se a origem solicitante possui permissão explícita para interagir com o recurso pretendido. Durante o preflight, o navegador envia automaticamente cabeçalhos como Origin, Access-Control-Request-Method e Access-Control-Request-Headers, informando ao servidor qual método HTTP e quais cabeçalhos personalizados serão utilizados na requisição real.

O servidor, por sua vez, deve responder com cabeçalhos como Access-Control-Allow-Origin, Access-Control-Allow-Methods e Access-Control-Allow-Headers, indicando se autoriza ou não o prosseguimento da requisição original. Caso o servidor não retorne os cabeçalhos esperados ou não permita explicitamente algum dos parâmetros solicitados, o navegador bloqueia a requisição subsequente, mesmo que o servidor esteja funcional. Esse bloqueio garante que scripts de páginas externas não consigam interagir com recursos de outras origens sem autorização explícita, preservando as restrições impostas pela Same-Origin Policy.

A ilustração acima apresenta a requisição preflight e a respectiva resposta trocadas entre a origem “cliente.cors.tcc:5001” (cliente) e “servico.cors.tcc:3000” (API). É possível observar os cabeçalhos enviados automaticamente pelo navegador para verificar se a operação solicitada é permitida, bem como os cabeçalhos retornados pelo servidor que determinam se a resposta poderá ser aceita pela origem requisitante.

6.2 Condições para ocorrência de Requisições Preflight

O navegador executa uma requisição Preflight apenas quando identifica que uma operação realizada por um script representa um potencial risco de segurança para a aplicação web. Esse tipo de requisição, enviada com o método OPTIONS, é utilizado pelo mecanismo de CORS para verificar, antes da requisição principal, se o servidor realmente autoriza o compartilhamento de recursos com a origem que está tentando acessá-lo. Entretanto, nem toda requisição executada por meio das APis fetch ou XMLHttpRequest aciona automaticamente um Preflight. Isso ocorre somente quando a operação não se enquadra na categoria de requisição simples.

Para que uma requisição seja considerada simples e, portanto, não gere um Preflight, ela deve atender a três condições definidas pela especificação do W3C. A primeira refere-se ao Método HTTP utilizado, que deve obrigatoriamente ser GET, HEAD ou POST. A segunda condição relaciona-se aos cabeçalhos permitidos: O navegador só aceita o uso de Accept, Accept-Language, Content-Language e Content-Type (com restrições específicas). Qualquer outro cabeçalho adicionado pelo desenvolvedor, como Authorization, X-API-Key ou cabeçalhos personalizados torna a requisição complexa e obriga o navegador a realizar o Preflight. A terceira condição diz respeito ao valor do cabeçalho Content-Type, que, quando presente, deve ser um dos seguintes: application/x-www-form-urlencoded, multipart/form-data ou text/plain. Qualquer outro tipo, como application/json, modifica o comportamento padrão e exige a verificação prévia do servidor.

É importante destacar que o simples fato de uma requisição ter sido gerada programaticamente por JavaScript, seja por meio de fetch ou XMLHttpRequest não é suficiente, por si só, para acionar o Preflight. O fator determinante é a requisição não atender aos critérios de simplicidade estabelecidos acima. O navegador permite que scripts realizem requisições simples diretamente, mas aplica rigidamente a Same-Origin Policy na leitura das respostas. Dessa forma, mesmo que a requisição seja enviada, o navegador bloqueará o acesso ao corpo da resposta caso o servidor não inclua um cabeçalho Access-Control-Allow-Origin compatível com a origem solicitante ou com o caractere coringa "*".

Quando a requisição se origina de uma ação direta do usuário, como clicar em um link ou enviar um formulário HTML, o navegador interpreta o evento como uma navegação de nível superior (top-level navigation). Nesses casos, o mecanismo de CORS não é aplicado, pois não há execução de scripts tentando acessar respostas vindas de outras origens, o navegador apenas realiza a navegação normalmente, sem compartilhamento de dados entre origens dentro de um contexto JavaScript. Assim, requisições originadas de interações legítimas do usuário não passam por validações de CORS nem por Preflight, enquanto aquelas enviadas de forma programática por scripts ficam sujeitas tanto às verificações de CORS quanto às restrições da Same-Origin Policy.

7. Configurações permissivas

A falha mais comum é a Reflexão de Origem Arbitrária. Nesse cenário, o servidor lê o valor do cabeçalho Origin enviado pelo navegador e o copia indiscriminadamente para o cabeçalho de resposta Access-Control-Allow-Origin. Embora essa prática facilite o desenvolvimento ao permitir que múltiplos domínios acessem a API sem a necessidade de manutenção de uma lista de permissões (allowlist), ela instrui o navegador a permitir que compartilhe a resposta com qualquer site que tenha feito a requisição, inclusive sites maliciosos.

Erros em expressões regulares são frequentes, por exemplo, uma regra criada para autorizar exemplo.com pode acidentalmente autorizar exemplo.com.sitemalicioso.net ou atacante-exemplo.com, permitindo que adversários registrem domínios similares para contornar as restrições e poder ler respostas a partir de requisições feitas desses domínios.

Além disso, existe o risco associado ao valor null. Algumas aplicações autorizam explicitamente a origem null na tentativa de suportar desenvolvimentos locais ou arquivos abertos diretamente pelo navegador. No entanto, atacantes podem forçar o envio da origem null através de iframes em modo sandbox, conseguindo acesso privilegiado a recursos que deveriam estar protegidos.

Essas configurações tornam-se críticas quando combinadas com o cabeçalho Access-Control-Allow-Credentials: true. Se o servidor reflete a origem e habilita credenciais simultaneamente, ele permite que um site atacante execute requisições autenticadas em nome da vítima, o que permite a realização de ações sensíveis e obtenção de dados privados de usuários, uma vez que o navegador da vítima enviará os cookies de sessão automaticamente e aceitará a resposta devido à política permissiva.

Dito isto, é correto afirmar que a má configuração do CORS também serve como um potencializador em casos de vulnerabilidades de Cross-Site Request Forgery(CSRF). Em sua forma tradicional, o CSRF é uma vulnerabilidade que se aproveita do comportamento padrão do browser de enviar cookies de sessão automaticamente sob certas condições. No entanto, esse ataque busca apenas realizar ações que alteram o estado do servidor (como realizar uma transferência ou alterar uma senha), sem que o atacante consiga visualizar a resposta da requisição. A má configuração do CORS permite que domínios externos leiam a resposta de requisições autenticadas, e o que era apenas um ataque de execução às cegas se transforma em um cenário de exfiltração de dados. Isso permite que o atacante não apenas execute a ação, mas também capture informações sensíveis retornadas pelo servidor.

8. Referências

AWATI, Ravul; WIGMORE, Ivy. What is monolithic architecture in software? TechTarget, 2024. Disponível em: https://www.techtarget.com/whatis/definition/monolithic-architecture.

ZETTLER, Kev. What is a distributed system? Atlassian, 2024. Disponível em: https://www.atlassian.com/br/microservices/microservices-architecture/distributed-architecture.

BARTH, Adam. HTTP State Management Mechanism. RFC 6265. Internet Engineering Task Force (IETF), 2011. Disponível em: https://datatracker.ietf.org/doc/html/rfc6265.

FIELDING, R. et al. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2616. IETF, 1999. Disponível em: https://datatracker.ietf.org/doc/html/rfc2616/.

FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Irvine: University of California, 2000. Tese (Doutorado). Disponível em: https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#fig_5_3.

CHEN, Jianjun et al. We Still Don't Have Secure Cross-Domain Requests: An Empirical Study of CORS. Usenix Security, 2018. Disponível em: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-chen.pdf.

VAN KESTEREN, Anne. Cross-Origin Resource Sharing. W3C Recommendation. W3C, 2014a. Disponível em: https://www.w3.org/TR/2014/REC-cors-20140116/.

VAN KESTEREN, Anne. Cross-Origin Resource Sharing W3C Recommendation 16 January 2014. WHATWG, 2014b. Disponível em: https://www.w3.org/TR/2020/SPSD-cors-20200602/#simple-method.

VAN KESTEREN, Anne. Fetch --- Living Standard. WHATWG, 2024. Disponível em: https://fetch.spec.whatwg.org/#http-cors-protocol.

STACEY, Thomas. Exploiting trust: Weaponizing permissive CORS configurations. Outpost24, 2025. Disponível em: https://outpost24.com/blog/exploiting-permissive-cors-configurations/.

GOLINELLI, Matteo et al. Mind the CORS. Trento: University of Trento, 2023. Disponível em: https://iris.unitn.it/retrieve/handle/11572/399025/726435/Mind-the-CORS.pdf.

ALBENIZ, ZIHAYAN. Definitive Guide to Same-origin Policy (SOP). 2018. Disponível em: https://www.invicti.com/white-papers/whitepaper-same-origin-policy.