Portal do cliente, área do revendedor, painel de pedidos, sistema de agendamento, intranet de RH. Quase toda empresa média já pediu, ou vai pedir, um desses. Todos são sistemas web: programas que rodam no navegador, com login, e que guardam informação que não é pública.
Os guias que aparecem primeiro na busca explicam bem a arquitetura e o ciclo de vida do software, e param aí. Este artigo faz o mesmo percurso — o que é, como funciona, como se desenvolve, onde hospedar e quanto custa — e acrescenta o que falta neles: o controle de acesso, a parte que separa um sistema de um site e que quase nunca aparece como linha no orçamento.
O que é sistema web?
Sistema web é um software acessado pelo navegador, em que a lógica e os dados ficam num servidor. O usuário não instala nada: abre um endereço, faz login e trabalha. Quando ele salva um pedido, a informação vai para um banco de dados central e fica disponível para quem tem permissão de vê-la.
O termo cobre coisas de tamanhos muito diferentes. Um formulário de inscrição com painel para a equipe aprovar os pedidos já é um sistema web. Um ERP inteiro rodando na nuvem também é. O que eles têm em comum são três elementos: usuários identificados, perfis com permissões distintas e dados que pertencem a alguém.
Vale um aviso sobre a busca: boa parte de quem digita "sistema web" no Google procura a tela de login de um sistema que já usa, como o de um software contábil. Este texto é para quem está do outro lado — a empresa que quer mandar fazer um.
Qual a diferença entre site e sistema web?
Um site institucional mostra a mesma coisa para todo mundo. Um sistema web mostra coisas diferentes para cada pessoa, conforme quem ela é. Essa frase resume a diferença, mas a tabela ajuda a ver o que ela muda no projeto:
| Site | Sistema web | |
|---|---|---|
| Quem acessa | Qualquer visitante, sem identificação | Usuários com login, separados por perfil |
| O que cada um vê | O mesmo conteúdo para todos | Só os dados e as funções do seu perfil |
| Dado guardado | Conteúdo público e, no máximo, contatos de formulário | Pedidos, contratos, cadastros, histórico de cliente |
| Principal risco | Página fora do ar ou desfigurada | Um usuário ver ou alterar o dado de outro |
| Como se testa a entrega | As páginas abrem e o formulário chega | Cada perfil é testado contra o que não deveria acessar |
Comparativo elaborado pela Alliance Comunicação a partir da prática de projetos web.
Na prática, a fronteira é borrada. Uma loja virtual é um site na vitrine e um sistema no "minha conta". Uma área restrita para clientes baixarem boletos transforma o site institucional num pequeno sistema web, com todas as obrigações que isso traz.
Como funciona um sistema web por dentro?
O modelo clássico é o cliente-servidor. O navegador é o cliente: desenha as telas e envia o que o usuário faz. O servidor recebe esses pedidos, aplica as regras do negócio e conversa com o banco de dados. Na maior parte dos sistemas atuais, essa conversa acontece por uma API, um conjunto de endereços que respondem a pedidos como "listar meus pedidos" ou "cancelar o pedido 4821".
Três camadas aparecem em quase todo projeto:
- Front-end — o que roda no navegador: telas, formulários, botões. É o que o usuário vê e, por isso, o que ele pode manipular.
- Back-end — o que roda no servidor: regras de negócio, autenticação (quem é você) e autorização (o que você pode fazer).
- Banco de dados — onde ficam os registros, cada um ligado a um dono: o pedido é de um cliente, o contrato é de uma empresa.
O detalhe que importa para quem contrata está na segunda camada. Esconder um botão na tela não impede ninguém de chamar o endereço que esse botão chamaria. Se a checagem de permissão estiver só no front-end, qualquer pessoa com um pouco de conhecimento consegue contorná-la. A regra de quem pode o quê precisa viver no servidor.
Por que o controle de acesso é o ponto mais frágil de um sistema web?
Porque ele é invisível quando funciona e só aparece quando falha. Nenhum usuário reclama de não conseguir ver o pedido do vizinho, e nenhum teste de "a tela abre?" descobre que ele conseguiria. A OWASP, fundação sem fins lucrativos que publica a lista de referência dos riscos em aplicações web, mede o tamanho do problema:
O número precisa ser lido com cuidado: "alguma forma da falha" inclui desde um descuido de baixo impacto até a exposição de uma base inteira de clientes. Mas a mensagem para quem contrata é direta. Se nenhuma aplicação testada escapou, o seu sistema também não vai escapar por acaso — só por especificação e teste.
A lista completa da edição 2025 do OWASP Top 10 traz, depois do controle de acesso, configuração insegura, falhas na cadeia de fornecimento de software, falhas de criptografia, injeção, design inseguro, falhas de autenticação, falhas de integridade de software ou dados, falhas de registro e alerta e o tratamento inadequado de condições excepcionais. Várias delas também dependem de decisões de escopo, mas nenhuma tem a frequência da primeira.
Quais são as falhas de controle de acesso mais comuns?
A própria OWASP descreve os casos típicos, e eles são menos sofisticados do que o nome sugere:
Traduzindo para o dia a dia de um portal de clientes:
- Troca de número na URL — o cliente abre /pedido/4821, troca para /pedido/4822 e vê o pedido de outra empresa. O sistema checou que ele estava logado, mas não que o pedido era dele.
- Página de administração alcançável — o menu de admin não aparece para o usuário comum, mas o endereço /admin responde se alguém digitá-lo.
- API que só protege a leitura — listar pedidos exige permissão, mas o endereço que altera ou apaga um pedido aceita qualquer usuário logado.
- Permissão que não sai com a pessoa — o funcionário desligado ou o representante que trocou de região continua com o acesso antigo porque ninguém revisou os perfis.
Nenhum desses casos exige um invasor genial. A maioria é descoberta por um usuário curioso, um concorrente que virou cliente ou um ex-funcionário. É exatamente por isso que o risco não pode ficar implícito no contrato.
Como desenvolver um sistema web, fase por fase?
O ciclo de vida de um software tem nomes diferentes em cada metodologia, mas as fases se repetem. O que muda neste artigo é onde o controle de acesso entra em cada uma delas — porque, se ele aparecer só no fim, fica caro corrigir.
1. Levantamento de requisitos
Define o que o sistema faz e para quem. Aqui nasce a matriz de perfis: uma tabela com cada tipo de usuário nas linhas, cada tela ou ação nas colunas e, em cada cruzamento, "vê", "altera" ou "não acessa". Sem ela, a regra de permissão fica na cabeça do programador.
2. Arquitetura e design
Escolhe linguagem, banco de dados, forma de login e hospedagem. É a fase de decidir que o acesso é negado por padrão — tudo o que não for explicitamente liberado fica bloqueado — e que cada registro sabe a quem pertence.
3. Desenvolvimento
As telas e as regras são construídas, em geral em ciclos curtos com entregas parciais. Cada endereço da API precisa conferir duas coisas: se o usuário está autenticado e se aquele registro específico é dele ou do perfil dele.
4. Testes e homologação
Além de testar se as funções funcionam, testa-se se o que não deveria funcionar de fato falha. Um usuário de cada perfil tenta acessar o que a matriz diz que ele não acessa. Para sistemas com dado sensível, vale um pentest com reteste das correções antes de abrir para os clientes.
5. Implantação e operação
O sistema vai para o servidor definitivo e passa a ser usado. Começa a parte mais longa do ciclo: correções, atualizações de componentes, revisão periódica de quem tem acesso a quê e registro das tentativas de acesso negadas.
6. Evolução e desativação
Todo sistema ganha funções novas, e cada função nova é uma linha nova na matriz de perfis. Quando o sistema é aposentado, os dados precisam ser migrados ou eliminados de forma controlada — não esquecidos num servidor que ninguém mais paga para atualizar.
O que exigir no escopo e no aceite de um sistema web?
Orçamentos de sistema costumam listar telas e funcionalidades: cadastro de clientes, painel de pedidos, relatório mensal. Raramente listam o comportamento esperado de cada perfil diante do que ele não pode fazer. É esse vazio que transforma a falha número 1 da OWASP em surpresa depois da entrega.
Os itens que valem colocar no contrato, com redação que o fornecedor consiga cumprir e o gestor consiga conferir:
- Matriz de perfis aprovada antes do desenvolvimento, como anexo do escopo.
- Acesso negado por padrão: qualquer tela ou endereço novo nasce bloqueado e só é liberado para os perfis listados.
- Teste de troca de identificador: em cada tela que mostra um registro, um usuário tenta abrir o registro de outro trocando o número na URL. O resultado esperado é recusa.
- Checagem de permissão na API para criar, alterar e apagar, não só para listar. Os métodos POST, PUT e DELETE entram no roteiro de teste.
- Área administrativa inacessível a usuários comuns e a quem não está logado, mesmo digitando o endereço.
- Registro das tentativas negadas e um processo para remover acessos de quem saiu da empresa ou mudou de função.
Dá para criar um sistema web com IA?
Dá para acelerar muito. Ferramentas de geração de código montam telas, cadastros e até a API a partir de uma descrição em texto, e um protótipo que levaria semanas sai em dias. Para validar uma ideia com usuários reais, isso é uma vantagem enorme.
O cuidado é que a IA entrega o que foi pedido, e quase ninguém pede "garanta que o cliente A não veja o pedido do cliente B". O código gerado tende a checar se o usuário está logado e parar aí — exatamente o padrão que a OWASP descreve como falha. Por isso a matriz de perfis e o roteiro de testes de aceite valem mais, e não menos, quando o sistema é feito com IA.
A outra pergunta é de propriedade. Plataformas que geram e hospedam o sistema em um só lugar podem dificultar a saída depois. Vale o mesmo raciocínio de criar site com IA e o que fica preso na plataforma: antes de começar, confirme se o código e o banco de dados podem ser exportados.
Como hospedar um sistema web?
Um sistema web precisa de mais do que uma hospedagem de site. Ele roda código no servidor, mantém um banco de dados e guarda informação que não pode se perder. As opções mais comuns:
- Servidor virtual (VPS) — controle total e custo previsível, mas alguém precisa cuidar de atualizações, cópias de segurança e monitoramento.
- Plataforma gerenciada na nuvem — o provedor cuida da infraestrutura e escala sozinho; o custo cresce com o uso.
- Hospedagem compartilhada com suporte a aplicações — serve para sistemas pequenos e internos, com limites de processamento e de acesso ao servidor.
Independentemente da escolha, três perguntas precisam de resposta escrita: em nome de quem está a conta, com que frequência os dados são copiados e onde essa cópia fica, e quem aplica as atualizações de segurança. O guia sobre o que o plano de hospedagem não diz traz a lista completa de perguntas.
Quanto custa desenvolver um sistema web?
Não existe preço de tabela honesto para sistema web, porque o custo é a soma de decisões. Um portal com dois perfis e cinco telas e uma plataforma com dez perfis, integrações e aplicativo são produtos de ordens de grandeza diferentes. O que dá para fazer é entender o que empurra o preço para cima:
| Fator | Puxa o custo para baixo | Puxa o custo para cima |
|---|---|---|
| Perfis de usuário | Um ou dois perfis com regras simples | Muitos perfis, hierarquias e permissões por registro |
| Integrações | Nenhuma ou só exportação de planilha | ERP, CRM, gateway de pagamento, assinatura digital |
| Dado tratado | Informação interna, sem dado pessoal sensível | Dado de saúde, financeiro ou documentos de clientes |
| Testes de segurança | Roteiro de aceite feito pela própria equipe | Pentest externo com reteste antes de cada grande entrega |
| Operação depois da entrega | Uso interno, poucos usuários | Acesso de clientes, disponibilidade alta, suporte contínuo |
Fatores de custo organizados pela Alliance Comunicação a partir de projetos de desenvolvimento.
Dois conselhos práticos. Primeiro, peça o orçamento separando construção, testes e operação mensal — é comum o valor da construção parecer baixo porque a manutenção ficou de fora. Segundo, desconfie de proposta em que segurança aparece como uma linha genérica. Os mesmos princípios de quanto custa criar um site valem aqui, com o peso extra da camada de usuários.
Quais erros mais encarecem um sistema web depois da entrega?
- Começar pelas telas, não pelos perfis — quando a matriz de permissões aparece depois, metade da API precisa ser refeita.
- Confiar no botão escondido — tirar a opção do menu não bloqueia o endereço que ela chama.
- Aceitar a entrega testando só o caminho feliz — homologar apenas o que deve funcionar, sem tentar o que deveria falhar.
- Deixar a conta de hospedagem no nome do fornecedor — a troca de parceiro vira negociação de refém.
- Nunca revisar acessos — o sistema nasce seguro e, dois anos depois, tem ex-funcionários com login ativo.
Por onde começar o seu sistema web
Antes de pedir orçamento, escreva em uma página quem vai usar o sistema, o que cada tipo de usuário precisa fazer e o que ele nunca pode ver. Essa página é o rascunho da matriz de perfis e já melhora a qualidade das propostas que você vai receber — fornecedor bom faz perguntas sobre ela; fornecedor fraco ignora.
Se o sistema vai nascer ao lado de site, CRM e automações, vale olhar o conjunto antes de contratar a peça. O diagnóstico de marketing gratuito da Alliance leva cerca de 30 minutos e mostra onde a tecnologia está segurando o crescimento. E, quando a decisão for construir, o time de desenvolvimento web e apps entra com a matriz de perfis e o roteiro de aceite já no escopo — e com tecnologia e segurança para testar o que não deveria funcionar.