Escala e segurança no frontend

Quando começamos a estudar desenvolvimento frontend, normalmente aprendemos HTML, CSS e JavaScript. Pouco tempo depois surgem frameworks como Angular e React. Mas alguns conceitos de arquitetura, escalabilidade e segurança se deparam com os desenvolvedores somente quando as aplicações ficam mais robustas, e é nisso que vamos nos aprofundar nesse artigo.

Como uma aplicação frontend funciona?

Primeiramente precisamos entender o fluxo básico de uma aplicação web.

Usuário
   ↓
Navegador
   ↓
Frontend
   ↓
API
   ↓
Banco de Dados

O frontend possui algumas responsabilidades:

• Exibir informações
• Capturar ações do usuário
• Enviar requisições ao backend
• Armazenar dados temporariamente
• Garantir uma boa experiência de uso

Mas ele não é responsável pela segurança principal da aplicação. Voltaremos a esse assunto mais adiante.

Como o frontend obtém dados?

Imagine um sistema bancário.

Ao abrir a tela de saldo:

Frontend
   ↓
GET /saldo
   ↓
Backend
   ↓
Banco

O frontend faz uma requisição para obter ou alterar dados, e existem várias formas de fazer isso.

Requisições tradicionais

Angular:

this.http.get('/api/saldo')

React:

fetch('/api/saldo')

ou

axios.get('/api/saldo')

Na prática o objetivo é o mesmo: buscar informações do servidor.

O problema das atualizações em tempo real

Agora imagine um chat. Não queremos ficar atualizando a página toda a página cada vez que novas mensagens surgirem, e para fazer isso temos algumas estratégias.

Polling

O frontend pergunta periodicamente (por exemplo, realiza uma chamada a cada 5s) ao backend:

Tem mensagem nova?
Tem mensagem nova?
Tem mensagem nova?

Fluxo:

Frontend
   ↓
API
   ↓
Resposta

Vantagem:

• Conceito simples de entender e implementar

Desvantagem:

• Muitas das requisições podem ser desnecessárias recebendo mais retornos negativos do que dados alterados.

WebSocket

Em vez do frontend fazer chamadas constatemente perguntando:

Tem mensagem nova?

O servidor envia um retorno e avisa diretamente:

Nova mensagem!

Fluxo:

Frontend ←→ Backend

Ideal para:

• Chats
• Jogos
• Monitoramento em tempo real

Como o frontend evita requisições desnecessárias?

Imagine que um usuário visite a mesma página várias vezes por dia. Seria desperdício baixar todos os arquivos que formam essa página novamente do zero, por isso trabalhamos com o cache.

O que é cache?

O cache é uma cópia temporária de dados. O objetivo é reutilizar informações já baixadas no navegador, e com isso, impedir requisições desnecessárias para baixar arquivos iguais ou similares os que já foram baixados anteriormente, economizar rede e realizar carregamentos mais rápidos, já os mesmos estão salvos no navegador.

Cache em memória

Angular (com RxJS) :

shareReplay(1)

O shareReplay() é um operador do RxJS que compartilha o resultado de uma requisição ou observable entre múltiplos assinantes e mantém o último valor em cache, evitando execuções ou chamadas HTTP repetidas.

React:

Para manter as respostas em memória, são utilizadas bibliotecas como:

• O TanStack Queryé uma biblioteca de gerenciamento de estado do servidor que realiza cache, sincronização, atualização automática e controle do ciclo de vida de dados obtidos por APIs.
• SWRé uma biblioteca de busca de dados que utiliza a estratégia Stale-While-Revalidate, exibindo dados em cache imediatamente enquanto busca versões atualizadas em segundo plano.

Local Storage

É uma forma simples de realizar a persistência de dados no dispositivo do usuário mesmo quando ele fechar o navegador. Salva ou dados em formato de chave e valor.

Usado geralmente para armazenar preferências do usuário na aplicação como:

• Tema escuro
• Configurações
• Aceites

Reduz a necessidade de buscar informações repetidamente no backend, melhorando a experiência do usuário e diminuindo chamadas à API. Entretanto, os dados aqui armazenados podem ser lidos e alterados por qualquer script executado na página, tornando-o inadequado para armazenar informações sensíveis como tokens de autenticação, senhas ou dados financeiros.

IndexedDB

O IndexedDB é um banco de dados local nativo do navegador que permite armazenar grandes volumes de dados estruturados de forma persistente no dispositivo do usuário.

É utilizado para aplicações que precisam armazenar muitos dados localmente, funcionar offline ou manter informações complexas sem depender constantemente do backend.Permite consultas rápidas a grandes quantidades de dados e possibilita o funcionamento parcial ou total da aplicação mesmo sem conexão com a internet.

Muito utilizado em:

• PWAs
• Aplicações offline

Tem uma capacidade de armazenamento muito maior que o LocalStorage, suporta objetos complexos, índices de pesquisa e operações assíncronas. Por outro lado, sua API é mais complexa de utilizar, exigindo mais código ou bibliotecas auxiliares para gerenciamento eficiente.

Cache HTTP

É um mecanismo que permite ao navegador, proxy ou CDN armazenar respostas de requisições HTTP para reutilizá-las posteriormente, evitando novas consultas ao servidor.

É utilizado para reduzir o tempo de carregamento de páginas, diminuir o consumo de banda e reduzir a quantidade de requisições enviadas ao backend. Melhora significativamente a performance da aplicação e reduz a carga nos servidores, pois muitos recursos podem ser reutilizados sem necessidade de novo download. Entanto, se mal configurado, pode fazer o usuário visualizar informações desatualizadas ou gerar inconsistências entre cliente e servidor.

Cache-Control: max-age=3600

Neste exemplo, o navegador reutilizará a resposta durante uma hora.

Tipos de cache

+----------------------+---------------------+--------------------------+-------+
| Tipo              | O que é             | Persiste       | Melhor Uso        |
+----------------------+---------------------+--------------------------+-------+
| Memory Cache      | Cache em RAM        | Não            | Dados temporários |
| RxJS Cache        | Cache de Observable | Não            | APIs Angular      |
| React Query Cache | Cache de consultas  | Não            | APIs React        |
| Session Storage   | Armazenamento aba   | Até fechar aba | Sessão            |
| Local Storage     | Armazenamento local | Sim            | Preferências      |
| IndexedDB         | Banco de dados      | Sim            | Offline           |
| Service Worker    | Cache de recursos   | Sim            | PWA               |
| HTTP Cache        | Cache do navegador  | Sim            | Assets            |
+----------------------+---------------------+--------------------------+-------+

Cache e Cookies são a mesma coisa?

Não. Essa é uma confusão comum.

Cookies x Cache

+----------------------+----------------------+----------------------+
| Aspecto              | Cookies              | Cache                |
+----------------------+----------------------+----------------------+
| Objetivo             | Identificar usuário  | Armazenar recursos   |
| Enviado ao servidor  | Sim                  | Não                  |
| Tamanho              | Pequeno              | Grande               |
| Segurança            | Crítica              | Baixa relevância     |
| Performance          | Pode prejudicar      | Melhora              |
+----------------------+----------------------+----------------------+

Cookies

Cookies são pequenos arquivos de texto armazenados pelo navegador para manter informações relacionadas ao usuário, à sessão ou ao comportamento da aplicação entre diferentes requisições.

Como:

• Gerenciamento de sessão
• Autenticação
• Preferências e personalização da navegação

São enviados automaticamente pelo navegador em cada requisição para o domínio correspondente, facilitando a manutenção de sessões e autenticação.

Os pontos de atenção são seu tamanho e segurança: possuem tamanho limitado e, quando mal configurados, podem ser alvo de ataques como roubo de sessão (Session Hijacking), XSS e CSRF.

Tipos de Cookies

+------------+---------------------+-------------+------------------+
| Tipo       | Persistência        | Segurança   | Uso              |
+------------+---------------------+-------------+------------------+
| Session    | Sessão              | Média       | Login            |
| Persistent | Configurável        | Média       | Preferências     |
| Secure     | Configurável        | Alta        | HTTPS            |
| HttpOnly   | Configurável        | Muito Alta  | Tokens           |
| SameSite   | Configurável        | Alta        | Proteção CSRF    |
+------------+---------------------+-------------+------------------+

Como as páginas são renderizadas?

Agora precisamos responder uma pergunta importante:

Quem monta a página?

CSR (Client Side Rendering)

CSR é uma estratégia em que a renderização da interface acontece no navegador do usuário. O servidor envia um HTML básico e os arquivos JavaScript. Após o download, o framework (Angular ou React) executa no navegador e monta toda a interface.

Um ponto positivo é reduzir a carga no servidor e proporciona uma navegação muito fluida após o carregamento inicial. Entanto, o primeiro carregamento pode ser mais lento e o SEO pode ser mais difícil de otimizar.

Fluxo:

HTML vazio
↓
JavaScript
↓
Página pronta

Quando é utilizado?

Em sistemas internos como ERP, CRM, Internet Banking, sistemas de RH, painéis administrativos e aplicações onde o usuário normalmente precisa estar autenticado, e o SEO não é primordial. Angular e React tradicional funcionam assim.

SSR (Server Side Rendering)

Nessa estratégia o servidor gera o HTML completo da página antes de enviá-lo ao navegador. A cada requisição, o servidor executa a aplicação, monta o HTML com os dados necessários e envia a página pronta para o usuário.

Fluxo:

Servidor
↓
HTML pronto
↓
Navegador

O forte dessa estratégia é a melhora significativamente o SEO e reduz o tempo necessário para exibir o conteúdo inicial da página. Como ponto de atenção temos o aumenta do consumo de recursos do servidor e adiciona complexidade à arquitetura da aplicação. Geralmente é utilizado para E-commerces, marketplaces, portais de notícias, sites imobiliários e qualquer aplicação pública cujo conteúdo precise ser indexado pelos mecanismos de busca de forma rápida.

SSG (Static Site Generation)

Aqui as páginas são geradas antecipadamente durante o processo de build da aplicação. Antes da publicação do sistema, o framework cria arquivos HTML estáticos que são entregues diretamente aos usuários quando acessam o site.

Fluxo:

Build
↓
HTML
↓
Deploy

Oferece excelente performance, baixo custo de infraestrutura e ótima indexação pelos buscadores, pois quando os indexadores visitam a sua página, o conteúdo já está todo estruturado, ele não necessita esperar o conteúdo sem baixado e executado para criar a indexação.

Já por outro lado, as atualizações de conteúdo normalmente exigem a geração de um novo build e um novo deploy da aplicação. Com isso, é indicado para blogs, documentações técnicas, landing pages, sites institucionais e portfólios, aplicações que não executam atualizações constantes de conteúdo.

ISR (Incremental Static Regeneration)

ISR (Incremental Static Regeneration) é uma evolução do SSG (Static Site Generation) que permite atualizar páginas estáticas automaticamente sem a necessidade de gerar toda a aplicação novamente.

As páginas são geradas estaticamente, mas após um período configurado o framework pode recriá-las em segundo plano quando houver novas requisições. Combina a performance do conteúdo estático com a capacidade de atualização frequente dos dados. Entretanto, possui uma arquitetura mais complexa e depende de suporte específico do framework utilizado.

Pode se encaixar bem para E-commerces, marketplaces, catálogos de produtos, portais de conteúdo e aplicações que precisam de SEO alto, excelente performance e atualizações frequentes de informação.

Comparação entre tipos de renderizações

+------+-------------------------+-----------+--------------------+----------------+----------------+-------------------+
| Tipo | O que é                 | SEO       | Performance Inicial| Atualização    | Custo Servidor | Custo Navegador   |
+------+-------------------------+-----------+--------------------+----------------+----------------+-------------------+
| CSR  | Renderiza no navegador  | Médio     | Média              | Excelente      | Baixo          | Alto              |
| SSR  | Renderiza no servidor   | Excelente | Alta               | Excelente      | Alto           | Médio             |
| SSG  | Gera páginas estáticas  | Excelente | Muito Alta         | Ruim           | Muito Baixo    | Baixo             |
| ISR  | SSG com regeneração     | Excelente | Muito Alta         | Boa            | Baixo          | Baixo             |
+------+-------------------------+-----------+--------------------+----------------+----------------+-------------------+

Como aplicações grandes compartilham dados?

Imagine uma aplicação com diferentes componentes:

Header
Sidebar
Perfil
Dashboard

Todos estes precisam saber quando um usuário está logado/deslogado, e passar dados manualmente entre componentes rapidamente vira um problema.

Gerenciamento de Estado

Conforme uma aplicação cresce, ela passa a armazenar cada vez mais informações durante sua execução.

Essas informações podem representar dados vindos do backend, preferências do usuário ou até mesmo comportamentos temporários da interface.

Chamamos de estado (state) qualquer informação que pode mudar ao longo da execução da aplicação e que influencia o que será exibido para o usuário.

Exemplos:

• Usuário autenticado
• Carrinho de compras
• Tema claro ou escuro
• Lista de notificações
• Dados de um formulário
• Página atual de uma tabela
• Resultado de uma busca
• Modal aberto ou fechado

Estado local (Local State)

O estado local é a forma mais simples de gerenciamento de estado. Ele é utilizado quando apenas um componente precisa acessar determinada informação. E nesse caso não faz sentido compartilhar essa informação com toda a aplicação.

Exemplos mais comuns:

• Modal aberto ou fechado
• Campo de busca
• Aba selecionada
• Botão carregando
• Contador local
• Validação de formulário

Estado compartilhado (Shared State)

O estado compartilhado surge quando uma mesma informação precisa ser utilizada por vários componentes da aplicação ao mesmo tempo.

Um exemplo disso é quando o usuário realiza login. A partir desse momento, diversos componentes precisam conhecer informações sobre esse usuário:

• Header: exibe o nome do usuário.
• Sidebar: exibe as opções permitidas.
• Dashboard: carrega dados personalizados.
• Perfil: exibe informações da conta.
• Configurações: permite alterar preferências.

Todos estes componentes dependem do mesmo dado referente a autenticação do usuário.

Estado global (global state)

É considerado como se fosse uma especialização do estado compartilhado. É um dado disponível praticamente para toda a aplicação.

Exemplos:

• Usuário logado
• Tema global
• Idioma
• Permissõe

Estado do servidor (Server state)

Esse é um dos conceitos mais importantes atualmente. São dados cuja fonte verdadeira está no backend. E o papel do frontend nisso é apenas fazer o cache e sincronizar esses dados.

Exemplos:

• Produtos
• Pedidos
• Clientes
• Saldo bancário

Estado de Sessão (Session State)

Representa informações válidas apenas durante a sessão do usuário. A sessão do usuário geralmente inicia quando ele realiza o login na aplicação e finaliza com o loggout, mas também, pode ser encerrada após um tempo expecífico ou quando a aba do navegador é fechada. Normalmente tem seus dados armazenado em Cookies, SessionStorage ou Memória RAM.

Exemplos:

• Token atual
• Dados do usuário autenticado
• Permissões

Estado de navegação (Navegation State)

Representa informações relacionadas à rota atual.

Exemplos:

• /produtos
• /produto/123
• ?page=2
• ?sort=price

Estado Persistente (Persistent State)

Diferentemente dos outros tipos de estados, que tem suas informações removidas ao atualizar a página ou encerrar a sessão, o Estado Persistente continua com seus dados armazenados. Geralmente suas informações são armazenadas em LocalStorage, IndexedDB e Cookies.

Exemplos:

• Tema escuro
• Preferências
• Idioma

Tipos de persistencias

+----------------------+---------------------------+----------------------+----------------------+
| Estado               | Descrição                 | Duração              | Armazenamento        |
+----------------------+---------------------------+----------------------+----------------------+
| Local State          | Estado do componente      | Enquanto existir     | Memória (RAM)        |
| Global State         | Compartilhar dados        | Enquanto app executa | Memória (RAM)        |
| Session State        | Dados da sessão           | Até fechar aba       | Session Storage      |
| Persistent State     | Dados permanentes         | Longo prazo          | Local Storage/DB     |
| Server State         | Dados da API              | Configurável         | Cache + API          |
| URL State            | Estado da navegação       | Enquanto URL existir | URL                  |
| Form State           | Dados de formulários      | Durante edição       | Memória (RAM)        |
| Cache State          | Evitar novas consultas    | Configurável         | Cache (RAM/Disco)    |
+----------------------+---------------------------+----------------------+----------------------+

Escalabilidade

Escalar não significa apenas suportar mais usuários.

Também significa:

• Mais desenvolvedores
• Mais funcionalidades
• Mais módulos
• Ou até, mais projetos relacionados

Lazy Loading

Uma das principais preocupações em aplicações frontend modernas é o tempo de carregamento inicial. Se todos os arquivos de uma aplicação forem enviados ao navegador logo no primeiro acesso, o usuário precisará baixar uma quantidade muito maior de código do que realmente precisa naquele momento e levará um longo tempo de carregamento até conseguir visualizar a página completa e interagir com ela.

E nesse ponto que o Lazy Loading auxilia, carregando apenas aquilo que o usuário precisa naquele momento para o fluxo atual no qual ele está no sistema. O carregamento dos componentes é feito por demanda de uso.

Design System

O Design System é um conceito frequentemente associado à escalabilidade frontend. Ele consiste em um conjunto padronizado de:

• Componentes
• Cores
• Tipografia
• Espaçamentos
• Ícones
• Padrões de interação

Seu objetivo é garantir consistência visual e comportamental entre diferentes aplicações.

Em Angular e React, normalmente é implementado através de bibliotecas compartilhadas de componentes. Exemplos conhecidos incluem o Google Material Design e o IBM Carbon Design System.

Monorepos (Monolithic Repository)

Monorepo é uma estratégia de organização de código (arquitetura de distribuição) onde múltiplos projetos, aplicações e bibliotecas são mantidos dentro de um único repositório. O principal objetivo é facilitar o compartilhamento de código, a padronização de ferramentas e a manutenção de componentes reutilizáveis entre diferentes aplicações da empresa.

No Angular, essa abordagem é muito comum através de ferramentas como Nx, que permitem criar múltiplas aplicações e bibliotecas compartilhadas dentro da mesma estrutura.

No React, ferramentas como Turborepo, Nx e Lerna são frequentemente utilizadas para atingir o mesmo objetivo.

Entre os principais benefícios estão a reutilização de código, a padronização de processos, a simplificação de refatorações globais e a facilidade de compartilhamento de bibliotecas internas.

Como pontos de atenção, o repositório pode crescer significativamente, os pipelines de build tendem a se tornar mais complexos e a curva de aprendizado para novos desenvolvedores costuma ser maior.

O Monorepo é especialmente indicado quando várias aplicações compartilham componentes, regras de negócio ou bibliotecas comuns.

Microfrontend

É uma arquitetura que divide uma aplicação frontend em várias aplicações menores e independentes. A ideia é aplicar ao frontend um conceito semelhante ao dos microserviços no backend.

Com variados projetos independentes, cada equipe possui autonomia para evoluir seu próprio módulo sem depender diretamente das demais.

O principal objetivo é aumentar a escalabilidade organizacional, permitindo que diferentes times trabalhem simultaneamente em áreas distintas do sistema. Com isso temos divisão de responsabilidades e deploys independentes.

No Angular e no React, uma das abordagens mais comuns atualmente é a utilização de Module Federation, recurso disponibilizado pelo Webpack que permite carregar partes da aplicação de forma distribuída. Também existem implementações utilizando Single-SPA, iframes, Web Components e integração por rotas.

Entre os benefícios estão a independência das equipes, deploys desacoplados, redução de conflitos entre times e maior escalabilidade para organizações grandes.

Como desvantagens, surgem desafios relacionados à comunicação entre aplicações, padronização visual, compartilhamento de dependências e aumento da complexidade arquitetural.

Tipos de arquitetura

+--------------+----------------------+-------------------+------------------+----------------------+------------------+
| Arquitetura  | Objetivo             | Repositório       | Time             | Deploy               | Ambientes        |
+--------------+----------------------+-------------------+------------------+----------------------+------------------+
| Monorepo     | Centralizar projetos | Único             | Compartilhado    | Geral ou parcial     | Compartilhados   |
| Microfrontend| Dividir aplicações   | Um ou vários      | Independentes    | Independente         | Independentes    |
+--------------+----------------------+-------------------+------------------+----------------------+------------------+

Segurança no Frontend

Na prática, o frontend é a primeira camada de contato com o usuário e também uma das principais superfícies de ataque de uma aplicação. Entender segurança frontend não significa apenas impedir invasões, mas também reduzir riscos, dificultar ataques e proteger a experiência do usuário.

O frontend nunca é confiável

Uma regra importante deve ser lembrada: tudo que roda no navegador está sob controle do usuário.

Isso significa que um usuário pode:

• Alterar o HTML da página.
• Modificar o JavaScript carregado.
• Alterar requisições HTTP.
• Inspecionar respostas da API.
• Manipular LocalStorage.
• Manipular SessionStorage.
• Modificar Cookies não protegidos.
• Executar scripts próprios.

Por isso, o frontend nunca deve ser considerado uma fonte confiável de validação.

Principais ameaças no Frontend

As vulnerabilidades mais comuns em aplicações web modernas normalmente envolvem:

• XSS (Cross-Site Scripting)
• CSRF (Cross-Site Request Forgery)
• Roubo de Tokens
• Dependências comprometidas
• Scripts de terceiros maliciosos
• Exposição de informações sensíveis
• Clickjacking

XSS (Cross-Site Scripting)

O XSS ocorre quando um invasor consegue executar JavaScript dentro da aplicação. Um dos ataques mais comuns.

Uma das formas de se proteger é transformar caracteres especiais como texto puro. Outro ponto importante é evitar inserir HTML arbitrário principalmente de apis que injetam html, neste caso é indicado utilizar mecanismos de sanitização.

Os frameworks e bibliotecas modernas ajudam a mitigar isso. No caso do Angular, já possui proteção nativa bastante forte contra XSS e opções de sanitização. No React também protege contra o XSS, mas exige mais atenção quando se trabalha com HTML dinâmico. A renderização de HTML vindo dos arquivos JSX já são protegidos.

CSP (Content Security Policy)

É uma camada adicional de proteção e delimita quais scripts podem ser executados. Mesmo que seja injetado um código malicioso, sua execução é bloqueada pelo navegador. O CSP é enviado pelo backend pelo cabeçalho HTTP de resposta, que quando é recebido pelo navegador, o mesmo passa a seguir estas regras. O Angular ou React normalmente não configuram CSP. Quem envia é a infraestrutura/backend.

Exemplo:

HTTP/1.1 200 OK

Content-Security-Policy: script-src 'self'

CSRF (Cross-Site Request Forgery)

O CSRF ocorre quando um usuário autenticado executa ações sem perceber. Isso pode acontecer quando um usuário visita um site malicioso que tenta utilizar algum de seus cookies para realizar alguma ação em outra aplicação.

Para impedir isso, deve-se utilizar o SameSite Cookies.

Set-Cookie:
SameSite=Strict

Isso é enviado pelo backend no momento da criação do cookie que ao chegar ao navegador, o cookie vai ser armazenado junto com essa regra. Essa regra vai impedir o envio automático do cookie em diversos cenários externos.

Principais otimizações de segurança

+------------------+---------------------------+----------------------------------+
| Proteção         | Configurada Onde?         | Objetivo                         |
+------------------+---------------------------+----------------------------------+
| CSP              | Backend/Servidor/CDN      | Bloquear scripts não autorizados |
| SameSite         | Backend (cookie)          | Evitar CSRF                      |
| HttpOnly         | Backend (cookie)          | Impedir acesso via JavaScript    |
| Secure           | Backend (cookie)          | Permitir apenas HTTPS            |
| X-Frame-Options  | Backend/Servidor Web      | Evitar Clickjacking              |
| frame-ancestors  | CSP                       | Evitar Clickjacking              |
+------------------+---------------------------+----------------------------------+

Uso de tokens

Evitar armazenar os tokens no LocalStorage, e sim, os armazenar em cookies com HttpOnly, Secure e SameSite. Desta forma, o JavaScript não consegue ler o token, o cookie só trafega via HTTPS e com isso há proteção adicional contra CSRF.

Clickjacking

Ocorre quando um site malicioso tenta esconder sua aplicação dentro de um iframe, ou seja, o site adiciona sua aplicação dentro dele.

Como prevenir?

O backend envia os cabeçalhos HTTP para evitar a execução do seu site em um iframe:

X-Frame-Options: DENY

ou

Content-Security-Policy:
frame-ancestors 'none'

E o navegador quando recebe essas regras, ele bloquea o carregamento do iframe.

E se o computador do usuário estiver infectado?

Essa é uma pergunta muito interessante.

Imagine:

Malware
↓
Injeta script
↓
Página aberta

Nenhum framework consegue impedir completamente isso.

Nem Angular.

Nem React.

Nem qualquer outro.

O computador comprometido pertence ao atacante.

Por isso, o backend deve sempre realizar camadas de validação e proteção das entradas e ações realizadas pelo frontend. Toda regra crítica de negócio, autorização, autenticação e validação deve ser implementada e validada também no backend.