# O que essa API protege, e o que não protege [#o-que-essa-api-protege-e-o-que-não-protege] > Pergunta: "o que essa API me protege, e o que ela não protege?" ## Credencial de transporte (host e guest) [#credencial-de-transporte-host-e-guest] `credential` é uma string opaca, obrigatória nas duas pontas (`createHost`/`joinRoom`), nunca decodificada por esta lib. O nome é neutro por decisão — não `apiKey`, não `token` — justamente para não prometer validação que a lib não faz. **Quem valida a credencial de fato depende de onde o servidor está implantado, e a lib não tem como saber isso nem declarar isso.** No deploy pretendido, o caminho do guest passa pelo gateway (PWA → gateway → rede interna), então a credencial é validada ali. Fora desse perímetro, não é. **A lib não sabe em qual dos dois casos está — e não existe flag para declarar isso.** É a única coisa que impede alguém (integrador ou agente) de ler "credencial obrigatória" como "logo está protegido": ela é obrigatória para o transporte, não é prova de autorização. ## `x-api-key` está depreciada [#x-api-key-está-depreciada] Nenhuma página desta documentação explica como usá-la — se aparecer em algum lugar, é só na lista do que morreu. ## A lista de limites, junto (não espalhada em outras páginas) [#a-lista-de-limites-junto-não-espalhada-em-outras-páginas] | mecanismo | o que protege | o que **NÃO** protege | | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **login (`credential` obrigatória)** | reduz quem pode tentar — precisa ter conta | **não é autorização de sala.** Credencial é de conta, não escopada por sala: qualquer conta logada que tenha o `joinCode` ou o link ainda entra. Estar logado ≠ estar autorizado àquela sala específica. | | **`approval_and_code`** (recomendado para o caso do microfone, **não exigido pela API**) | barreira humana (aprovação) + código não público, juntos — `open`/`code` sozinhos não têm barreira contra um terceiro entrando em paralelo | `displayName` é auto-declarado, nunca verificado — não distingue um impostor de um guest legítimo na janela de espera. Aprovar o guest certo **não impede aprovar um segundo** guest também (multi-guest concorrente é suportado, sem promessa extra — ver abaixo). `room.onJoinRequest` notifica o host; `room.approveJoin(requestId)`/`room.rejectJoin(requestId)` decidem o pedido — ver [receita-microfone.md](/pt/docs/event-room/latest/markdown/receita-microfone). | | **`maxGuests`** (⚠️ **requer servidor com suporte a `max_guests` — ainda não entregue**; ver `pacote-plataforma.md` A4 no repo de spec) | limita **quantidade** de guests admitidos | **não decide identidade.** Não impede um impostor de chegar **antes** do guest legítimo — só limita quantos entram no total. Não substitui a decisão humana da aprovação, e não decide **quem**, dentre N aceitos, é o guest certo. | ## Multi-guest concorrente [#multi-guest-concorrente] Suportado, sem promessa extra: a lib não fixa origem, não dá um handle por guest, e não ordena nada entre eles. Quem usa `approval` com N > 1 decide manualmente, caso a caso, quem aprovar — a lib não ajuda a distinguir. ## Custo da forma opaca (Standard Schema / `payload()`) [#custo-da-forma-opaca-standard-schema--payloadt] Declarar um evento como Standard Schema ou via `payload()` (ver [eventos.md](/pt/docs/event-room/latest/markdown/eventos)) faz o fingerprint do handshake comparar **só o nome** daquele evento, não a forma concreta — quem escolhe essas camadas abre mão da rede de proteção do fingerprint para aquele evento especificamente. É uma fraqueza **invisível** enquanto não se olha o resultado do handshake como dado (ver [eventos.md](/pt/docs/event-room/latest/markdown/eventos)); a mitigação é justamente expor esse resultado como valor consultável em runtime, não escondê-lo em log. ## Dependência de perímetro, sem flag para declarar [#dependência-de-perímetro-sem-flag-para-declarar] Resumo da seção de credencial acima, porque é a mais fácil de esquecer: a segurança real desta API depende do perímetro de rede em que o serviço está implantado — gateway na frente do caminho do guest, ou não — e **a lib não verifica isso em runtime, não tem como, e não existe um parâmetro para o integrador declarar "estou atrás do gateway"**. Documentar essa dependência aqui é a mitigação; não existe mitigação em código para isso.