O maior problema de criar site com inteligência artificial não é o layout. É segurança e vulnerabilidade. Site em JavaScript costuma expor API no navegador. Dá para proteger o front e o painel admin mesmo quando os dois nasceram de vibe coding. No vídeo eu passei quatro dicas para site criado com IA, no meu caso rodando em Cloudflare Workers: associações (bindings) para não vazar chave, Turnstile na área de membros, cuidado extra na autenticação em JavaScript e Cloudflare Access no Zero Trust para o admin. A ordem é a da gravação. Nenhuma delas conserta sozinha um código que grava dado sem conferir quem pediu.
Use Workers com bindings para banco, IA e storage sem chave no cliente. Coloque Turnstile na entrada pública que escreve dado. Peça criptografia de sessão de verdade na área de membros. Tranque o painel admin com Cloudflare Access, fora do domínio do Worker. Evite escrita anônima; se precisar de like ou formulário, o desafio entra no caminho.
- Quatro dicas
- Bindings, Turnstile, auth no JS, Access
- Onde o segredo mora
- Worker, não o .env no GitHub
- Admin
- Login no domínio da Cloudflare, não no Worker aberto
Dica 1: Workers e bindings, chave fora do navegador
A primeira dica é usar Cloudflare Workers, que para mim é o melhor caminho para site serverless na borda. No ecossistema existe um sistema para não expor chave de API nem variável de ambiente no cliente: binding, associação em português. No painel eu abri um projeto, no caso o meu painel de administrador — que já estava protegido, e eu explico isso mais abaixo.
Com associações você liga banco, Worker, CDN, inteligência artificial, sem chave de API. A conexão fica dentro da conta da Cloudflare: um projeto fala com o outro recurso do mesmo ecossistema. Você não cola credencial para o front consumir o banco. O front conversa com o Worker; o Worker já tem o D1, o R2 ou o Workers AI associados. Se ainda precisar de uma API externa, o back consome essa API e o Worker entrega o resultado, sem rota que devolva o segredo.
Aquela credencial que mora em arquivo .env e sobe para o GitHub some desse desenho. Quando a variável é de fora — um ID, um segredo que não pode vazar — você cria nas configurações do Worker, como secret. Assim não fica no repositório, não fica no notebook se alguém abrir a pasta, não fica no JavaScript que o navegador baixa. A documentação da Cloudflare trata binding e secret exatamente assim: valor injetado no runtime, não string no bundle.
- Crie o Worker (ou deixe a IA criar) e publique na sua conta.
- Em configurações, associe D1, R2, KV ou Workers AI pelo binding, sem gerar chave de API para o front.
- Segredo externo vira secret no painel, não linha no wrangler.jsonc e não .env commitado.
- Confira no DevTools que o JavaScript do site não contém token de provedor nem connection string.
Dica 2: Turnstile na área de membros, não “turnstile” no chute
A segunda maneira de se sentir seguro numa área de membros pública é o Turnstile. Eu sempre me confundo no nome — já chamei de outra coisa — mas o produto é Turnstile, o desafio da Cloudflare. É o captcha deles. No site SK Sensei, a plataforma de japonês, o clique em Entrar já dispara o desafio. Passa rápido. Dá para configurar no domínio com regra de segurança, sem montar um aplicativo à parte.
O captcha clássico de marcar a caixa, no estilo Google, pede API e um app só para ele. Codex ou Claude Code conseguem fazer essa configuração ou te passam a instrução. Eu não tratei o passo a passo de painel no vídeo de propósito: a IA do seu computador segue a documentação se você pedir Turnstile no formulário de login. O que importa é o lugar: a porta em que um desconhecido tenta entrar, assinar ou mandar dado.
Turnstile não é login. Ele reduz automação abusiva na ação pública. Quem entra de verdade ainda precisa de sessão, senha ou mágica com e-mail. Misturar as duas coisas — achar que o quadradinho substitui identidade — deixa a área de membros aberta para quem passou do desafio uma vez.
Dica 3: área de membros em JavaScript pede criptografia de verdade
Não basta o desafio na porta. Na hora de a IA criar a área de membros para aluno ou assinante, em JavaScript, no próprio site, você precisa pedir segurança com nome: criptografia, sessão, autenticação. Existem jeitos mais e menos seguros de autenticar. Cookie sem flag, token no localStorage, senha no cliente — isso a ferramenta faz se você não vetar.
Depois que estiver funcionando, ainda falta checkup. JavaScript é chato nesse ponto: o código que autentica viaja para o navegador. Tudo que for decisão de “pode escrever no banco” tem que morrer no Worker, com binding e regra, não num if no front. Eu falei no vídeo para conversar com a IA e exigir isso, e depois revisar. Funcionando na tela não é o mesmo que fechado para quem cola a URL da API.
- Sessão httpOnly, segura, com tempo de vida curto.
- Senha com hash no servidor; nunca no JavaScript entregue.
- Rota de escrita autenticada no Worker, não só escondida no menu.
- Segundo checkup depois do “está no ar”: sessão inválida, cookie roubado, rota direta.
Dica 4: Cloudflare Access no admin, login fora do Worker
Se você quer um painel administrador, a função que eu achei mais interessante é o Cloudflare Access. Ele protege o painel de um jeito que o login nem mora no domínio do Worker. Redireciona para um domínio da própria Cloudflare, você entra com e-mail, ela manda código, você verifica. O incômodo: às vezes o e-mail demora. Por isso existem outros métodos — Google e vários que eu mostrei no Zero Trust, inclusive biometria, que eu ainda não tinha explorado a fundo.
O painel que eu mostrei ainda não estava totalmente responsivo. Eu estava editando. Mesmo assim já dava para ver todos os bancos dos sites, os próprios sites, automação, CDN, analytics, artigos e arquivos Markdown de site estático. Um único admin para vários projetos na Cloudflare. Essa centralização foi uma das razões de eu ter saído do WordPress. Eu cheguei a procurar CMS. Não me dei bem: a conexão vira API entre front e painel, e isso cria vulnerabilidade e complicação. Com Workers e bindings eu peço, a IA faz, conecta, publica. Se precisar mexer, é associação, variável e o arquivo wrangler.jsonc ou toml.
A tela de configuração do Access fica em Zero Trust, controle de acesso. Você cria o aplicativo, liga no Worker, define usuário, método de login. Zero Trust ainda abre DNS para proteger computador e rede; isso já é outro produto, mas mostra o tamanho do ecossistema. Eu não ganho nada para falar da Cloudflare. Queria um afiliado. Falo porque é a plataforma em que eu consegui site, segurança e CDN no mesmo lugar.
- No painel, abra Zero Trust > Access e crie um aplicativo para a URL do admin.
- Escolha o método de login (e-mail com código, Google ou outro da lista).
- Restrinja aos seus usuários; não deixe o aplicativo aberto para qualquer conta.
- Teste numa janela anônima: a URL do admin deve redirecionar para o login da Cloudflare antes de qualquer HTML do painel.
- Se o código por e-mail atrasar, cadastre um segundo método e use esse no dia a dia.
O fechamento: menos escrita anônima, mais camada
Se você quer criar site em JavaScript com IA e permanecer inteiro, evite escrita anônima. Like, comentário, formulário aberto — cada um é uma porta. Se a escrita for obrigatória, entra o Turnstile. Se o painel for completo, entra o Access. Bindings e secret cobrem a chave. Autenticação no Worker cobre a sessão. As quatro dicas trabalham juntas. Uma só, não.
Dúvida fica no comentário do vídeo ou no grupo de WhatsApp da descrição. Inscrição no canal, se ainda não for inscrito, é o outro convite do fechamento — e não substitui o checkup de segurança depois que a IA disser que terminou.
Na sequência
- Nenhuma chave de provedor no JavaScript do navegador nem no GitHub.
- Banco, R2 e Workers AI ligados por binding.
- Turnstile na ação pública que cria ou altera dado.
- Área de membros com sessão no Worker, não só tela de login bonita.
- Admin atrás de Cloudflare Access, testado em janela anônima.
Onde isso quebra
Colocar o .env no repositório “só para a IA achar a chave”.
Achar que Turnstile substitui login na área de membros.
Publicar o painel admin no mesmo hostname aberto do site.
Deixar rota de escrita no Worker sem identidade, porque o botão só aparece depois do login no front.
Confiar no primeiro “está seguro” da IA sem tentar a URL direta e a sessão inválida.
Perguntas frequentes
Binding elimina qualquer chave de API?
Elimina a chave entre o seu Worker e os produtos da própria Cloudflare (D1, R2, Workers AI). Serviço de fora ainda pode pedir secret — e esse secret fica no painel do Worker, não no navegador.
Turnstile é o captcha do Google?
Não. É o desafio da Cloudflare. No domínio dá para ligar com regra de segurança. O captcha clássico de caixa, no estilo Google, pede app e chave próprios.
Por que o login do Access não fica no meu domínio?
Porque o redirecionamento vai para a infraestrutura da Cloudflare antes de liberar o Worker. Quem não passou pela identidade nem vê o HTML do admin.
Dá para ter um CMS separado em vez do painel no Access?
Dá. Eu não me dei bem: a API entre CMS e front virou superfície nova. Com bindings eu edito Markdown e banco no próprio ecossistema.
Site só de leitura ainda precisa dessas quatro camadas?
Binding e secret continuam valendo se o Worker fala com serviço pago. Turnstile e Access entram quando existe escrita ou painel. Leitura pública sem formulário pede menos porta, não menos cuidado com chave.