Esconder um link administrativo da navegação não protege a operação que ele chamaria. O navegador pode enviar uma requisição diretamente para a rota da API, sem carregar a página do painel. Por isso, a checagem de acesso precisa ocorrer no servidor em todo caminho que lê ou altera dados privados. A interface pode redirecionar alguém sem sessão, mas essa checagem é uma conveniência adicional.

Separe autenticação de autorização

Autenticação responde quem está fazendo a chamada. Autorização responde se essa identidade pode executar a ação sobre aquele recurso. Um usuário autenticado pode não ser administrador do CMS. A rota deve confirmar a sessão e depois comparar identidade, papel, escopo ou outra regra definida pelo produto. Não aceite um campo isAdmin enviado pelo formulário como prova de permissão.

Se o servidor usa Firebase Admin SDK, considere que ele opera com credenciais privilegiadas e ignora as Security Rules do Firestore. A rota precisa bloquear chamadas não autorizadas antes de usar esse cliente. Limite o acesso da credencial por IAM, mantenha a chave fora do bundle e não retorne documentos internos na resposta da API.

Proteja o ciclo de vida da sessão

Uma sessão baseada em cookie precisa de transporte HTTPS e atributos compatíveis com o risco: HttpOnly reduz o acesso do JavaScript à credencial, Secure restringe seu envio a conexões HTTPS e SameSite controla parte do envio em requisições entre sites. Esses atributos se complementam; nenhum corrige uma autorização ausente no servidor. Defina expiração no servidor e invalide a sessão no logout.

Se o navegador envia o cookie automaticamente, avalie a exposição a CSRF nas operações que alteram estado. SameSite pode ajudar, mas a política depende dos fluxos de login, subdomínios e integrações. Use token CSRF ou validação de origem quando o desenho exigir. Requisições GET não devem publicar, excluir ou alterar conteúdo.

Proteja cada tipo de endpoint

Uma rota de listagem pública deve evitar rascunhos. Uma rota administrativa pode incluí-los depois de verificar a conta autorizada. POST, PUT, PATCH e DELETE precisam confirmar a permissão em cada chamada. Middleware pode fazer uma triagem inicial, mas não deve ser a única barreira se caminhos alternativos ou handlers internos acessam os mesmos dados.

Valide o corpo no servidor: tipo de conteúdo, campos obrigatórios, limites de tamanho, slug, status e tags. Responda com erros úteis sem expor stack trace, credenciais ou detalhes do banco. Registre tentativas negadas com contexto para investigação e sem gravar tokens ou conteúdo privado nos logs.

Teste a fronteira, não só a tela

Faça a chamada sem cookie, com cookie expirado e com uma conta autenticada sem privilégio administrativo. Confirme o status HTTP e que a operação não alterou o banco. Repita com a conta autorizada e verifique a gravação esperada. Teste também logout seguido de replay do cookie antigo, origem externa e payload maior que o limite aceito.

Compare o acesso pela interface com uma chamada direta à API. Se a interface bloqueia e a API aceita, a fronteira está no lugar errado. A política fica mais fácil de manter quando a função de autorização é única e cada rota a chama antes de acessar serviços privilegiados.

OWASP: Session Management Cheat Sheet · Firebase: regras de consulta e bibliotecas de servidor