Cibersegurança

Seu aplicativo criado com inteligência artificial funciona. Mas ele está seguro?

Entenda autenticação, autorização e os cuidados essenciais ao criar aplicações com inteligência artificial.

Evandro Gayer Gomes
Evandro Gayer Gomes
Ilustração de uma aplicação conectada a servidores e dados, protegida por elementos visuais de autenticação, autorização e segurança digital.

Introdução

Hoje, pessoas sem formação técnica e profissionais de diferentes áreas de uma empresa já conseguem criar portais, sistemas internos e ferramentas de automação com ajuda da inteligência artificial generativa. Esse modo de desenvolvimento, conhecido como vibe coding (programação guiada por instruções em linguagem natural), permite transformar uma descrição em uma aplicação funcional dentro de poucos dias.

Essa facilidade abre espaço para testar ideias, automatizar processos e criar soluções que antes exigiriam mais tempo e investimento. Quando a aplicação começa a processar faturas, documentos, dados de clientes ou credenciais de acesso, ela também passa a concentrar informações sensíveis e a participar de processos importantes para o negócio. Uma falha de segurança nesse estágio pode provocar acesso indevido, vazamento de dados e prejuízos para a empresa.

Por isso, avaliar uma aplicação exige ir além da pergunta “ela funciona?”. Também é preciso entender quem consegue entrar, como o sistema mantém esse acesso, quais ações cada pessoa pode realizar e onde essas regras são verificadas. Esses pontos correspondem a conceitos comuns no desenvolvimento de software, como autenticação, sessão, cookies e autorização.

Neste artigo, vamos explicar esses termos de forma acessível e mostrar como eles se aplicam a sites tradicionais, aplicações de página única e aplicativos móveis. Também vamos apresentar referências como a OWASP, o OAuth 2.0 e o OpenID Connect, além de discutir por que a revisão de profissionais experientes continua importante em aplicações criadas com inteligência artificial generativa.

Como conciliar produtividade e desenvolvimento seguro?

Desenvolver um protótipo rapidamente é uma forma válida de testar uma ideia antes de investir em uma solução completa. A inteligência artificial generativa encurta esse caminho ao ajudar a criar interfaces, regras de negócio e integrações a partir de instruções em linguagem natural.

O cuidado precisa aumentar quando o protótipo recebe dados reais, torna-se acessível pela internet ou começa a fazer parte da operação da empresa. Nesse momento, decisões sobre arquitetura, regras de acesso, proteção de dados e limites de uso passam a influenciar diretamente a segurança da solução. A responsabilidade por essas decisões permanece com as pessoas e empresas que colocam o sistema em funcionamento.

Em maio de 2026, Axios e WIRED publicaram reportagens sobre aplicativos criados por meio de vibe coding que permaneceram acessíveis publicamente e, em alguns casos, expuseram informações corporativas e pessoais. A pesquisa citada foi produzida pela empresa de segurança RedAccess, e as plataformas envolvidas contestaram partes da metodologia e atribuíram alguns casos às configurações escolhidas pelos usuários. Ainda assim, os jornalistas conseguiram verificar alguns aplicativos expostos.

O episódio mostra como o ganho de velocidade pode reduzir o intervalo entre criar um protótipo e disponibilizá-lo para usuários reais. Sem uma etapa equivalente de revisão, configurações inadequadas e falhas de controle de acesso também chegam à produção mais rapidamente. Para entender como isso pode acontecer, primeiro precisamos distinguir o teste do funcionamento esperado de uma avaliação de segurança.

Um aplicativo funcionando ainda pode ser um aplicativo inseguro

Quando alguém testa um aplicativo no dia a dia, normalmente verifica se o fluxo principal está de pé: o usuário consegue entrar, abrir uma fatura e atualizar as informações permitidas para sua conta.

Esses testes são úteis, mas eles mostram apenas o comportamento esperado. Segurança exige outro tipo de pergunta.

Em vez de perguntar se o cliente consegue ver a própria fatura, é preciso perguntar se ele consegue ver a fatura de outro cliente. Em vez de perguntar se o botão de administrador aparece só para quem deve usá-lo, é preciso perguntar se a função administrativa continua protegida mesmo que alguém tente chamá-la por fora da interface.

É como olhar uma loja por dois ângulos diferentes. No primeiro, você verifica se a porta abre e se o caixa registra a venda. No segundo, investiga se uma entrada reservada ficou destrancada ou se alguém consegue alcançar o estoque sem permissão.

Aplicativos criados com apoio da inteligência artificial generativa ampliam esse risco por um motivo simples: eles podem ser montados muito rápido por pessoas que ainda não dominam o raciocínio de segurança por trás das telas. A interface pode parecer profissional. O fluxo pode parecer completo. A aparência de acabamento não garante proteção real.

Pesquisas recentes reforçam esse ponto. No relatório de 2025 da Veracode, 45% das tarefas de geração de código avaliadas introduziram alguma vulnerabilidade conhecida. O estudo testou mais de cem modelos em tarefas e linguagens selecionadas, portanto esse percentual não representa uma taxa universal para todo código produzido com inteligência artificial. Ele demonstra, dentro do recorte estudado, que um modelo pode entregar código funcional e ainda reproduzir práticas inseguras.

Uma pré-publicação acadêmica disponível no arXiv, focada em tarefas escritas em Java, chegou a uma conclusão parecida. O estudo encontrou vulnerabilidades e defeitos nas respostas de diferentes modelos e observou que um bom desempenho funcional em benchmark (teste comparativo padronizado) não se traduziu automaticamente em melhor qualidade ou segurança geral. O fato de um sistema entregar a resposta certa em um teste ainda não demonstra que ele esteja pronto para trabalhar com dados e operações reais.

Reconhecer essa diferença estabelece o ponto de partida para uma avaliação mais segura. Antes de escolher tecnologias ou configurar o login, é preciso identificar quais dados, funções e processos da aplicação realmente precisam de proteção.

O primeiro passo é entender o que precisa ser protegido

Antes de discutir login, senha ou qualquer tecnologia específica, vale fazer uma pergunta mais básica: o que esse aplicativo protege?

Muita gente trata segurança como um aditivo colocado no final do trabalho, quase como um verniz. Na prática, ela começa quando você identifica quais informações e quais ações merecem proteção especial.

Pense em um portal simples para clientes. Ele permite criar conta, consultar faturas e conversar com um assistente baseado em inteligência artificial generativa. Já para o time interno, o mesmo sistema permite atualizar informações e administrar contas.

Agora as perguntas ficam mais concretas.

Quais dados são públicos e quais precisam permanecer privados? Quem pode apenas visualizar uma informação e quem pode alterá-la? Qual seria o impacto caso um cliente acessasse documentos de outra empresa? Essas perguntas conectam a segurança às consequências reais para o negócio.

Esse exercício é uma forma simplificada de threat modeling (modelagem de ameaças). O nome pode soar técnico, mas a ideia é prática: mapear o que pode dar errado, quem poderia explorar a situação e qual seria o dano para a empresa.

Mesmo uma análise inicial como essa já ajuda muito. Se o sistema apenas organiza tarefas internas sem dados sensíveis, o nível de cuidado exigido é um. Se ele guarda dados pessoais, documentos financeiros ou operações críticas, o patamar de responsabilidade muda.

É aqui que a participação de profissionais experientes começa a fazer diferença. Eles ajudam a enxergar caminhos de abuso que quase nunca aparecem para quem está olhando apenas para o fluxo normal de uso.

Depois de identificar os dados e as operações que precisam de proteção, o próximo passo é transformar essas necessidades em regras do sistema. Para acompanhar esse processo, vale entender três grupos de conceitos comuns no desenvolvimento de aplicações:

  • autenticação, que confirma a identidade de uma pessoa ou sistema;
  • sessão e cookie, que ajudam a aplicação a reconhecer o usuário nas interações seguintes;
  • autorização, que define quais dados e funções essa identidade pode acessar.

Esses conceitos acompanham uma sequência lógica. Primeiro, o aplicativo identifica o usuário. Depois, precisa manter esse acesso de forma segura. A cada nova solicitação, também deve verificar se aquela pessoa possui permissão para realizar a ação desejada. Vamos começar pela identificação.

O que é autenticação?

Autenticação é o processo de confirmar quem está fazendo um pedido ao sistema. Em linguagem simples, é a etapa em que o aplicativo tenta responder: "essa pessoa é mesmo quem diz ser?"

Isso pode acontecer com e-mail e senha, com uma passkey (chave de acesso) ou por meio de uma conta mantida por um provedor externo. A autenticação também acontece entre sistemas, quando um software precisa comprovar sua identidade antes de se conectar a outro.

Aqui vale um cuidado importante: autenticação não é sinônimo de tela de login. A tela é só a parte visível.

Como as senhas são guardadas? Como funciona a recuperação da conta? Contas mais sensíveis usam autenticação multifator, exigindo mais de uma forma de comprovar a identidade? O acesso expira e pode ser encerrado com segurança? Essas decisões fazem parte da autenticação tanto quanto a tela na qual o usuário digita a senha.

A OWASP, fundação internacional sem fins lucrativos que mantém projetos abertos para melhorar a segurança de software, trata autenticação como um sistema completo, não como um detalhe de interface. Seu guia prático de autenticação reúne recomendações sobre senhas, recuperação de conta, autenticação multifator e outros controles relacionados.

Imagine que um aplicativo permita redefinir uma senha por meio de um link que nunca expira e pode ser reutilizado. A tela de login pode parecer impecável, enquanto o caminho alternativo de acesso deixa a conta vulnerável. Em contas com acesso financeiro ou funções administrativas, medidas adicionais, como autenticação multifator, tornam-se ainda mais importantes. O nível de proteção deve acompanhar o impacto de um possível comprometimento.

Depois que a autenticação termina, a aplicação precisa reconhecer o usuário nas solicitações seguintes. Isso é necessário porque cada página aberta, botão acionado ou informação carregada pode gerar uma nova comunicação com o servidor. Sem um mecanismo de continuidade, o usuário teria de informar suas credenciais novamente em cada uma dessas ações.

A sessão representa o período em que a aplicação considera aquele usuário autenticado. Em um site tradicional, as informações principais dessa sessão costumam permanecer no servidor. O navegador recebe apenas um identificador aleatório que permite localizar a sessão correta. Esse identificador pode ser armazenado em um cookie, um pequeno dado que o navegador envia automaticamente ao site nas próximas solicitações.

Podemos comparar esse processo à entrada em um condomínio. A portaria verifica a identidade do visitante e registra sua entrada. Em seguida, entrega uma credencial temporária. O registro mantido pela portaria representa a sessão; a credencial entregue ao visitante cumpre o papel do cookie. Quando o visitante tenta acessar outra área, a credencial permite consultar o registro e confirmar que sua entrada continua válida.

Essa explicação também mostra por que o cookie precisa ser protegido. Se alguém copiar o identificador de uma sessão ativa, poderá tentar apresentá-lo ao servidor e agir como o usuário legítimo. Para reduzir esse risco, a aplicação deve usar conexões seguras, impedir o acesso desnecessário ao cookie por códigos executados no navegador, definir um prazo de expiração e invalidar a sessão durante o logout (encerramento da sessão).

O conteúdo de um cookie varia conforme a arquitetura. Ele não precisa guardar a senha nem todos os dados do usuário; em muitos sistemas, contém apenas o identificador necessário para localizar a sessão no servidor. Outras arquiteturas podem usar credenciais digitais diferentes, como tokens, que serão mencionadas mais adiante ao explicar aplicações de página única e aplicativos móveis.

Além da segurança, cookies exigem atenção do ponto de vista de privacidade. Um cookie necessário para manter a autenticação tem uma finalidade diferente de outro usado para acompanhar a navegação ou personalizar publicidade. Ao desenvolver uma aplicação, é preciso identificar quais cookies serão criados, quais dados eles armazenam, por quanto tempo permanecem ativos e se são compartilhados com terceiros.

No Brasil, esse tratamento deve considerar a Lei Geral de Proteção de Dados Pessoais (LGPD). Aplicações oferecidas a pessoas na União Europeia também podem estar sujeitas ao General Data Protection Regulation (Regulamento Geral sobre a Proteção de Dados), conhecido pela sigla GDPR, além das regras europeias específicas para privacidade nas comunicações eletrônicas. A necessidade de consentimento depende da finalidade e do contexto: cookies estritamente necessários ao funcionamento podem receber tratamento diferente daqueles usados para análise ou publicidade. A Autoridade Nacional de Proteção de Dados oferece orientações específicas sobre cookies, transparência e escolhas do usuário.

Com a identidade confirmada e a sessão mantida, ainda falta uma decisão em cada operação: determinar se aquele usuário pode acessar o dado ou executar a função solicitada. Essa é a responsabilidade da autorização.

O que é autorização?

Se autenticação responde quem entrou, autorização define o que essa pessoa pode fazer depois de entrar.

Imagine um portal em que cada cliente pode consultar as próprias faturas. Um usuário faz login, abre o endereço de uma fatura e percebe que o link termina em um número, algo como 1042. Então ele troca esse número por 1043. Se o sistema mostrar a fatura de outro cliente, existe uma falha grave de autorização.

Esse é um exemplo clássico de Insecure Direct Object Reference (referência direta insegura a objeto), também conhecida pela sigla IDOR. Atualmente, esse tipo de vulnerabilidade aparece na categoria Broken Access Control (controle de acesso quebrado) da OWASP. O nome técnico importa menos do que a lógica: o sistema confirmou a identidade do usuário, mas não verificou se ele podia acessar aquele recurso específico.

Para um negócio, as consequências são concretas. Uma fatura pode expor dados financeiros e um documento interno pode revelar informações pessoais ou comerciais. Além da perda de confiança, o incidente pode gerar fraude e obrigações regulatórias.

É por isso que um login válido nunca deve ser interpretado como autorização ampla. Uma pessoa pode estar corretamente identificada e, ainda assim, não ter o direito de ver, alterar, aprovar, exportar ou apagar determinado conteúdo.

Por que esconder um botão não protege uma função?

Esconder um botão, desabilitar um menu ou bloquear uma página visível no navegador melhora a experiência do usuário, mas não protege de verdade a função por trás da tela.

O motivo é simples. A parte visível do aplicativo roda no ambiente do próprio usuário. Quem controla o navegador ou o aplicativo instalado consegue observar pedidos, repetir chamadas, alterar parâmetros e tentar caminhos que a interface normal não mostra.

Em termos menos técnicos, seria como confiar que uma sala está protegida só porque a porta principal não tem placa. Se o corredor continua aberto e a fechadura não existe, qualquer pessoa curiosa pode tentar entrar do mesmo jeito.

Toda operação sensível precisa ser validada pelo lado que realmente controla os dados e as regras: o servidor (computador onde a aplicação fica hospedada), por meio de uma Application Programming Interface (Interface de Programação de Aplicações, ou API). Uma API é o canal pelo qual a interface envia solicitações ao servidor. É nesse servidor que o sistema deve conferir quem fez o pedido, qual ação foi solicitada e se aquela pessoa tem autorização para realizá-la.

O OWASP API Security Top 10:2023 reforça exatamente esse ponto ao colocar falhas de autorização entre os principais riscos de APIs. O documento também destaca que funções administrativas mal separadas e fluxos de negócio sem controle de abuso podem gerar danos mesmo quando o aplicativo parece funcional.

Como papéis e permissões organizam o acesso?

Aplicações pequenas costumam nascer com uma lógica simples: existe um usuário comum e existe um administrador. Em muitos casos, isso parece suficiente. À medida que o sistema cresce, essa divisão quase sempre fica curta demais.

Uma empresa pode ter funcionários, gestores e clientes com responsabilidades diferentes. Um atendente, por exemplo, pode consultar um cadastro para prestar suporte sem receber permissão para alterar dados de cobrança. O sistema precisa representar essas diferenças de forma explícita.

Aqui entram ideias como role (papel, ou tipo geral de responsabilidade), permission (permissão para uma ação específica), posse do recurso e isolamento entre clientes. Em sistemas usados por várias empresas, cada organização pode ser tratada como um tenant (inquilino ou cliente isolado dentro de uma plataforma compartilhada). Um erro nessa camada permite que dados de uma organização apareçam para outra.

Para quem cria software com inteligência artificial generativa, esse é um dos pontos mais traiçoeiros. A ferramenta pode gerar rapidamente telas, tabelas, filtros e consultas. Mas alguém ainda precisa definir as regras de convivência entre usuários, equipes e empresas diferentes. Essas regras não aparecem sozinhas.

Quando esse trabalho não é feito com cuidado, o sistema começa a confiar demais em informações enviadas pela própria interface. Por exemplo: aceitar que o navegador informe a qual empresa o usuário pertence, ou aceitar sem validação que determinada pessoa é administradora. É uma confiança perigosa.

Por que a arquitetura muda os cuidados de segurança?

Muitos problemas começam quando se supõe que toda aplicação funciona da mesma forma por dentro.

Um site tradicional, no qual o servidor monta as páginas e as envia prontas ao navegador, costuma usar uma sessão associada a um cookie (dado armazenado pelo navegador). Já uma Single-Page Application (aplicação de página única), conhecida pela sigla SPA, executa grande parte da interface no navegador e acessa dados por meio de APIs. Aplicativos móveis e integrações entre sistemas também precisam de credenciais e fluxos adequados aos seus ambientes.

Para um leitor não técnico, vale uma analogia simples. Proteger uma casa, uma loja e um galpão industrial envolve princípios em comum, mas a disposição das entradas, o fluxo de pessoas e o tipo de ativo guardado mudam completamente o desenho das travas, câmeras e rotinas.

Com software acontece algo parecido.

No navegador, o código enviado ao usuário pode ser inspecionado. Isso significa que não faz sentido tratar segredos embutidos nessa parte visível como se estivessem realmente escondidos. Em aplicativos móveis, vale lógica parecida: instalar o aplicativo no aparelho do usuário não transforma esse aparelho em cofre absoluto.

É aqui que aparecem tecnologias como OAuth 2.0 e OpenID Connect (conexão de identidade aberta). O OAuth 2.0 define mecanismos usados para conceder acesso limitado a aplicações. O OpenID Connect acrescenta uma camada de identidade, permitindo que o aplicativo confirme quem realizou o login. Essas tecnologias oferecem padrões consolidados, mas a segurança ainda depende da escolha do fluxo apropriado e de sua configuração.

Nesses fluxos, é comum usar um access token (token de acesso), uma credencial digital apresentada pela aplicação ao solicitar dados ou funções de uma API. Como ocorre com o identificador de sessão armazenado em um cookie, a exposição desse token pode permitir que outra pessoa use o acesso concedido. A forma correta de armazená-lo e renová-lo depende da arquitetura da aplicação.

Entrar com uma conta de um provedor externo resolve tudo?

Um provedor externo de identidade é um serviço especializado que autentica usuários para outras aplicações. É o que acontece quando um site oferece a opção “Entrar com Google” ou “Entrar com Microsoft”. Em vez de receber e verificar diretamente a senha, a aplicação direciona o usuário ao provedor escolhido. Depois da autenticação, o provedor envia uma confirmação verificável sobre a identidade daquela pessoa.

Esse modelo pode melhorar a experiência e reduzir a responsabilidade da aplicação pelo armazenamento de senhas. Protocolos como o OpenID Connect foram criados justamente para permitir esse tipo de integração de identidade entre sistemas.

A participação do provedor termina, em geral, na confirmação da identidade e no compartilhamento das informações autorizadas pelo usuário. As permissões internas continuam sob responsabilidade da aplicação. Se uma pessoa entra corretamente com uma conta externa e consegue visualizar o documento de outra empresa, a autenticação funcionou; a falha está na autorização do aplicativo.

Podemos comparar o provedor à recepção de um prédio terceirizada para conferir documentos e registrar visitantes. Essa recepção informa quem entrou, enquanto cada empresa dentro do prédio continua responsável por decidir quem pode acessar suas salas e arquivos. Da mesma forma, adotar um provedor de identidade ajuda a resolver uma parte do processo, mas não substitui as regras de acesso do sistema.

Erros comuns em aplicativos gerados rapidamente

Quando um aplicativo é montado com muita velocidade, geralmente precisamos nos atentar quanto a quatro itens:

  • considerar a presença de login como prova suficiente de segurança;
  • proteger apenas as telas, deixando as APIs sem a mesma verificação de autorização;
  • confiar em dados enviados pelo navegador para determinar a empresa, a permissão ou o valor de uma operação;
  • publicar credenciais, configurações ou ferramentas internas como parte de um ambiente acessível pela internet.

Pesquisas recentes sobre vibe coding ajudam a dar dimensão a esse risco. Ainda que a causa exata varie entre falha da plataforma, escolha do usuário e desenho inadequado do aplicativo, o padrão se repete: sistemas que pareciam úteis e prontos acabaram visíveis ou acessíveis além do que seus criadores imaginavam.

O que revisar antes de colocar o sistema em uso real?

Não é preciso transformar cada protótipo em um projeto de auditoria pesado. Mas também não é razoável tratar um sistema com dados reais como se fosse apenas um rascunho sem consequências.

Antes de colocar um aplicativo em uso real, vale revisar pelo menos cinco pontos.

Primeiro, quais dados e ações exigem proteção especial. Uma fatura e uma página institucional, por exemplo, raramente têm o mesmo nível de sensibilidade.

Segundo, quem pode ver, criar, alterar, aprovar, exportar ou apagar cada tipo de informação. Essa matriz de acesso pode parecer burocrática, mas evita boa parte das ambiguidades perigosas.

Terceiro, se as permissões são verificadas no sistema central, e não apenas na tela que o usuário enxerga.

Quarto, se o aplicativo expõe credenciais, arquivos, configurações ou áreas administrativas de forma indevida.

Quinto, se alguém testou o sistema com perfis realmente diferentes. Uma verificação simples consiste em criar dois clientes de empresas distintas e confirmar que nenhum deles consegue acessar os dados do outro, inclusive ao modificar endereços e solicitações enviados à API.

Por que a revisão de profissionais experientes continua importante?

A inteligência artificial generativa ampliou o acesso à criação de software. Mais empresas e profissionais agora conseguem transformar ideias em ferramentas reais com muito menos atrito, trazendo um ganho de produtividade significativo.

Mas segurança e escalabilidade continuam sendo disciplinas de julgamento, contexto e responsabilidade. Um sistema pode estar bem apresentado e ainda assim ter falhas em regras de acesso, organização de dados, consumo de recursos, recuperação de conta, segregação entre clientes, monitoramento e continuidade operacional.

Profissionais experientes da área de tecnologia continuam necessários nesse contexto. Eles ajudam a escolher a arquitetura, revisar os controles de acesso e identificar maneiras de abusar de um fluxo que parece seguro durante o uso normal. Também avaliam se o sistema poderá crescer sem se tornar caro, frágil ou difícil de manter. Essa análise separa um experimento local de um sistema que já deve ser tratado como parte da operação da empresa.

O próprio OWASP Application Security Verification Standard (Padrão de Verificação de Segurança de Aplicações), conhecido como ASVS, organiza requisitos de verificação de acordo com o nível de confiança necessário. A ideia de proporcionalidade é útil: quanto maior o impacto potencial do sistema, maior precisa ser o rigor da avaliação e do acompanhamento.

Se sua empresa está criando uma aplicação com inteligência artificial generativa ou precisa revisar uma solução antes de colocá-la em produção, nós podemos ajudar a avaliar a arquitetura, os controles de acesso e os riscos. Você pode entrar em contato conosco para conversarmos sobre o assunto.

Conclusão

A criação de software com inteligência artificial generativa já mudou a forma como empresas experimentam, constroem e lançam ferramentas. Isso traz uma vantagem competitiva real, acompanhada pelo risco de confundir velocidade com maturidade.

Um aplicativo que funciona pode continuar inseguro. Uma interface bonita pode esconder dados expostos, permissões frouxas e decisões improvisadas sobre identidade.

Para os negócios, vale usar inteligência artificial generativa para ganhar velocidade e abrir espaço para que mais pessoas participem da criação de software. Quanto mais o sistema se aproxima do uso real com dados, clientes e operações relevantes, maior se torna a importância da revisão por profissionais experientes.

A inteligência artificial generativa pode ajudar a escrever código e sugerir estruturas, bibliotecas e fluxos. A responsabilidade pelas consequências do sistema colocado em funcionamento permanece com as pessoas e empresas que o desenvolveram e publicaram.

Fontes

Leia Mais

Link copiado