Quando monto um site com IA, separo desde o começo o que o navegador pode mostrar do que só o servidor deve acessar. Essa escolha define onde guardar uma chave de API, como receber formulários sem aceitar qualquer requisição e quem pode entrar no painel que administra o site.
Bindings conectam o Worker aos recursos sem expor uma chave no navegador
HTML, CSS e JavaScript enviados ao navegador ficam visíveis para quem abre a página. A segurança vem de decidir o que cada parte pode fazer: a interface mostra os recursos públicos, e o Worker guarda as operações que exigem credenciais. Uma chave de API privada, senha de banco ou token de serviço não deve aparecer no JavaScript que vai para o navegador.
Nos Workers, conecto recursos como D1, R2 e Workers AI por bindings. O Worker recebe cada recurso pelo ambiente e acessa o serviço sem uma chave de Cloudflare embutida no front-end. Para APIs externas, guardo o token como secret na configuração do Worker. Binding e secret têm funções diferentes; nos dois casos, a página pública não recebe a credencial privada.
No computador, uso valores locais num arquivo de ambiente que o Git ignora; em produção, configuro o secret no ambiente hospedado. O Worker usa o valor e devolve somente o resultado de que a página precisa. Se alguém comprometer a conta de hospedagem ou o próprio servidor, ainda há trabalho de resposta a fazer, mas a chave não está publicada no repositório nem no código entregue a cada visitante.
Turnstile precisa ser validado pelo servidor
Para um formulário, cadastro ou botão de curtida aberto ao público, posso acrescentar Cloudflare Turnstile. O widget aparece na página e devolve um token para aquela tentativa. No SKSensei, ele aparece quando o aluno abre a tela de entrada. Essa checagem reduz parte do tráfego automatizado; login e permissões continuam sendo responsabilidade do sistema de usuários.
O widget só cumpre o papel de filtro quando o Worker envia o token ao Siteverify da Cloudflare e confirma o resultado antes de aceitar a operação. A página sozinha não valida o desafio. Cada token vale cinco minutos e só pode ser usado uma vez; se o envio atrasar ou a verificação falhar, peça uma nova confirmação.
Mesmo com Turnstile, a rota deve conferir os dados recebidos, aplicar limite de tentativas e decidir o que o visitante pode alterar. Desative gravações anônimas que não fazem parte do produto. Quando uma escrita pública é necessária, como num formulário de contato, proteja aquela ação e não permita que um dado enviado pelo visitante escolha livremente o registro a modificar.
Área de membros confere a sessão em cada operação
Cada rota que lê ou altera dados de um membro precisa conferir a sessão e a permissão para aquele registro. Esconder uma página ou botão no front-end não impede que alguém envie uma requisição diretamente para a API. A autorização tem de acontecer no servidor, antes de consultar ou gravar as informações.
Uma sessão de usuário deve viajar por HTTPS e ficar num cookie com atributos como Secure, HttpOnly e SameSite adequados ao fluxo. Assim, scripts comuns da página não conseguem ler o identificador de sessão. Um serviço de autenticação pronto também pode cuidar de cadastro, recuperação de conta e renovação de sessão; eu prefiro isso a manter esses mecanismos sem uma necessidade específica.
Depois de implementar, tento abrir uma URL privada sem login, uso uma sessão expirada e confiro se uma conta não consegue acessar os dados de outra. São três verificações simples que mostram se o servidor aplica a regra em cada operação.
Cloudflare Access fecha o painel administrativo para visitantes
Para um painel que só a equipe usa, Cloudflare Access verifica a identidade e as políticas antes de encaminhar a requisição ao Worker. Meu painel central reúne sites, bancos, arquivos, automações e métricas. Poder administrar vários projetos num mesmo lugar foi parte do que me levou a sair do WordPress; o acesso a essa área precisa acompanhar o poder que ela concentra.
Eu uso Access para ferramentas privadas da equipe e deixo o cadastro de clientes dentro do próprio produto. Cada aluno ou cliente precisa da sua conta, sessão e autorização para os dados que acessa; Access fica na entrada do painel interno.
Na minha experiência, o código de acesso por e-mail às vezes demora, então eu configuraria um provedor de identidade que a equipe já usa. Também confiro quais usuários a política permite. Access controla quem chega ao painel; a aplicação ainda verifica o que cada pessoa pode alterar. Para um painel central que administra dados e conteúdo, mantenho as duas verificações.