Preparatório Caixa TI: Desenvolvimento Web e APIs para ambientes corporativos

Arquitetura cliente-servidor no desenvolvimento web corporativo

Em ambientes corporativos, aplicações web normalmente seguem o modelo cliente-servidor: o cliente (navegador, app mobile ou outro sistema) envia requisições; o servidor processa regras de negócio, acessa dados e devolve respostas. Em integrações internas, um “cliente” pode ser outro serviço (microserviço, batch, sistema legado) consumindo uma API.

Fluxo básico (visão de prova)

• Cliente monta uma requisição (URL + método + headers + corpo opcional).
• Servidor valida, autentica/autorização, executa a operação e retorna status code, headers e body (quando aplicável).
• Intermediários podem existir: balanceadores, gateways de API, proxies e caches, que influenciam headers, roteamento e segurança.

HTTP: estrutura, métodos, códigos de status, headers e cookies/sessões

Estrutura de uma requisição e resposta HTTP

Uma requisição HTTP é composta por: (1) linha inicial (método, caminho, versão), (2) headers, (3) linha em branco, (4) body (opcional). A resposta tem: (1) linha inicial (versão, status code, motivo), (2) headers, (3) linha em branco, (4) body (opcional).

GET /api/v1/clientes?pagina=1&tamanho=20 HTTP/1.1
Host: exemplo.corp
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{ "itens": [], "pagina": 1, "tamanho": 20, "total": 0 }

Métodos HTTP mais cobrados

• GET: consulta recurso. Em geral não altera estado no servidor.
• POST: cria recurso ou executa ação não idempotente (ex.: processar pagamento).
• PUT: substitui recurso por completo (ou cria em um URI conhecido, dependendo do design).
• PATCH: atualização parcial.
• DELETE: remove recurso.
• HEAD: igual ao GET, mas sem body (útil para checar metadados).
• OPTIONS: descobre capacidades do endpoint; muito associado a CORS (pré-flight).

Idempotência (conceito de prova)

Uma operação é idempotente quando executá-la uma ou várias vezes produz o mesmo efeito final no servidor. Isso é importante para tolerância a falhas e retries (repetição automática) em redes instáveis.

• GET é tipicamente idempotente (não deveria alterar estado).
• PUT é idempotente (substituir o recurso pelo mesmo conteúdo repetidas vezes mantém o mesmo estado final).
• DELETE é idempotente (deletar de novo não muda o estado final: continua “não existe”, embora possa retornar 404/204 dependendo do design).
• POST geralmente não é idempotente (enviar duas vezes pode criar dois recursos/duas transações).

Códigos de status HTTP (mapa mental)

• 1xx: informativo (raros em prova prática).
• 2xx: sucesso. Exemplos: 200 OK, 201 Created (criação), 204 No Content (sucesso sem body).
• 3xx: redirecionamento. Ex.: 301, 302, 304 Not Modified (cache).
• 4xx: erro do cliente. Ex.: 400 Bad Request (requisição inválida), 401 Unauthorized (não autenticado/sem credenciais válidas), 403 Forbidden (autenticado, mas sem permissão), 404 Not Found, 409 Conflict (conflito de estado), 422 Unprocessable Entity (validação semântica falhou, comum em APIs).
• 5xx: erro do servidor. Ex.: 500, 502, 503.

Headers essenciais e o que eles sinalizam

• Content-Type: formato do body enviado (ex.: application/json).
• Accept: formatos aceitos pelo cliente (content negotiation).
• Authorization: credenciais (ex.: Bearer token).
• Cache-Control: regras de cache (ex.: no-store para dados sensíveis).
• ETag e If-None-Match: validação de cache e controle de concorrência otimista.
• Location: em 201 Created, aponta para o URI do recurso criado.
• Set-Cookie e Cookie: gerenciamento de estado via cookies.
• Origin, Access-Control-Allow-Origin: relacionados a CORS.

Cookies e sessões (diferença prática)

Cookie é um dado armazenado no cliente e enviado ao servidor a cada requisição para o domínio/escopo. Sessão é um estado mantido no servidor (por exemplo, dados do usuário autenticado), normalmente referenciado por um identificador de sessão guardado em cookie.

• Cookie de sessão: expira ao fechar o navegador (em geral).
• Cookie persistente: tem expiração definida.
• Boas práticas: usar flags HttpOnly (reduz acesso via JavaScript), Secure (somente HTTPS) e SameSite (mitiga CSRF).

REST em APIs corporativas: princípios, recursos e boas práticas

O que é REST (nível de prova)

REST (Representational State Transfer) é um estilo arquitetural para sistemas distribuídos. Em APIs RESTful, os endpoints representam recursos (ex.: /clientes, /contas/123), e as operações são expressas por métodos HTTP. A comunicação é stateless: cada requisição deve conter as informações necessárias para ser processada (por exemplo, token de autenticação), sem depender de estado de sessão no servidor para funcionar.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Modelagem de recursos (exemplos)

• Listar: GET /api/v1/clientes
• Detalhar: GET /api/v1/clientes/123
• Criar: POST /api/v1/clientes
• Atualizar completo: PUT /api/v1/clientes/123
• Atualizar parcial: PATCH /api/v1/clientes/123
• Excluir: DELETE /api/v1/clientes/123

Versionamento de API (por que e como)

Versionar evita quebrar consumidores quando a API muda. Formas comuns:

• Na URL: /api/v1/... (muito comum em prova e em corporações).
• Em header: Accept: application/vnd.empresa.v1+json (mais sofisticado).
• Por query: ?version=1 (menos recomendado).

Boas práticas: mudanças incompatíveis (breaking changes) exigem nova versão; mudanças compatíveis podem ser evoluções na mesma versão (ex.: adicionar campo opcional).

Paginação (conceito e padrão de resposta)

Paginação evita respostas gigantes e melhora desempenho. Dois padrões comuns:

• Offset/limit: ?pagina=1&tamanho=20 (ou ?offset=0&limit=20).
• Cursor-based: ?cursor=abc (melhor para listas grandes e dados mutáveis).

GET /api/v1/transacoes?pagina=2&tamanho=3 HTTP/1.1
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "itens": [
    {"id": 10, "valor": 100.00},
    {"id": 11, "valor": 50.00},
    {"id": 12, "valor": 25.00}
  ],
  "pagina": 2,
  "tamanho": 3,
  "total": 100
}

Passo a passo prático: desenhar um endpoint REST com paginação e validação

• 1) Defina o recurso: por exemplo, “transações” de uma conta: /contas/{id}/transacoes.
• 2) Defina o método: GET para consulta.
• 3) Defina parâmetros: pagina e tamanho (com limites, ex.: tamanho máximo 100).
• 4) Defina respostas: 200 com lista; 400 se parâmetros inválidos; 401/403 conforme segurança.
• 5) Defina contrato: Content-Type/Accept application/json; campos obrigatórios e opcionais.
• 6) Implemente validação: rejeitar tamanho negativo, pagina 0, etc.

Autenticação e autorização em APIs: OAuth2 e JWT (nível de prova)

Autenticação x autorização

• Autenticação: comprovar quem é o usuário/sistema (identidade).
• Autorização: verificar o que pode fazer (permissões/escopos/papéis).

OAuth2 (visão conceitual)

OAuth2 é um framework de autorização muito usado para permitir que um cliente acesse recursos em nome de um usuário ou de um sistema. Elementos típicos:

• Resource Owner: usuário (dono do recurso).
• Client: aplicação que quer acessar.
• Authorization Server: emite tokens.
• Resource Server: API que valida token e entrega recurso.

Em provas, costuma aparecer a ideia de token de acesso (access token) enviado no header Authorization: Bearer.

JWT (JSON Web Token) em alto nível

JWT é um formato de token (compacto) com três partes: header.payload.signature. O payload contém “claims” (ex.: sub, exp, roles/escopos). A assinatura permite verificar integridade e autenticidade do token.

• Não confundir: JWT não é “criptografia” por si só; normalmente é assinado. Pode ser também criptografado (JWE), mas o comum é JWS (assinado).
• exp: expiração; tokens devem ter validade curta.
• Boas práticas: validar assinatura, expiração, emissor (iss) e audiência (aud).

Passo a passo prático: chamada autenticada com Bearer token

• 1) Obter token: via fluxo definido (ex.: client credentials para integração sistema-sistema).
• 2) Chamar API: incluir header Authorization: Bearer <token>.
• 3) Interpretar retorno: 401 indica token ausente/inválido/expirado; 403 indica falta de permissão (escopo/role insuficiente).

GET /api/v1/contas/123 HTTP/1.1
Accept: application/json
Authorization: Bearer eyJhbGciOi...

Segurança em aplicações web: OWASP Top 10 (conceitual) e prevenções

OWASP Top 10 (visão geral para prova)

O OWASP Top 10 é uma lista de categorias de riscos comuns em aplicações web. Em nível conceitual, o foco é reconhecer o tipo de falha e a mitigação típica.

• Broken Access Control: controle de acesso falho (ex.: usuário acessa recurso de outro). Mitigação: checagem de autorização no servidor, princípio do menor privilégio.
• Cryptographic Failures: falhas no uso de criptografia (ex.: dados sensíveis sem proteção). Mitigação: TLS, armazenamento seguro, evitar dados sensíveis desnecessários.
• Injection: injeções (SQL, comandos, etc.). Mitigação: parametrização, validação, escaping, menor privilégio.
• Insecure Design: falhas de projeto (ausência de controles). Mitigação: threat modeling, requisitos de segurança.
• Security Misconfiguration: configuração insegura (headers ausentes, debug ligado). Mitigação: hardening, revisão de configuração, automação.
• Vulnerable and Outdated Components: dependências vulneráveis. Mitigação: inventário, atualização, SCA.
• Identification and Authentication Failures: autenticação fraca. Mitigação: MFA quando aplicável, políticas de senha, proteção contra brute force, sessões seguras.
• Software and Data Integrity Failures: integridade em pipelines/atualizações. Mitigação: assinaturas, controles de CI/CD, validação de artefatos.
• Security Logging and Monitoring Failures: logs/monitoramento insuficientes. Mitigação: logs de auditoria, alertas, correlação.
• Server-Side Request Forgery (SSRF): servidor faz requisições indevidas a alvos internos. Mitigação: allowlist de destinos, bloqueio de IPs internos, validação de URL.

Validação de entrada: regra de ouro

Entrada do usuário (body, query, path, headers) deve ser tratada como não confiável. Duas ideias-chave:

• Validação por allowlist: aceitar apenas formatos esperados (ex.: regex para CPF, limites numéricos).
• Normalização e limites: tamanho máximo de campos, tipos corretos, encoding consistente.

CSRF (Cross-Site Request Forgery): o que é e como mitigar

CSRF ocorre quando um site malicioso induz o navegador do usuário autenticado a enviar uma requisição para um sistema alvo, aproveitando cookies/sessão já existentes.

• Quando é mais comum: autenticação baseada em cookie (sessão) e endpoints que alteram estado (POST/PUT/DELETE).
• Mitigações típicas: token anti-CSRF, header customizado validado, SameSite em cookies, reautenticação para ações sensíveis.

XSS (Cross-Site Scripting): o que é e como mitigar

XSS ocorre quando a aplicação permite injetar scripts que serão executados no navegador de outros usuários. Pode ser armazenado (persistente) ou refletido.

• Mitigação: escapar/encode de saída conforme contexto (HTML, atributo, JS, URL), sanitização de HTML quando necessário, Content-Security-Policy (CSP), evitar inserir conteúdo não confiável diretamente no DOM.
• Boa prática: cookies de sessão com HttpOnly reduzem impacto de roubo via XSS (não elimina XSS).

SQL Injection: o que é e como prevenir

SQL Injection ocorre quando dados de entrada são concatenados em comandos SQL, permitindo alterar a consulta. Em provas, a prevenção mais cobrada é consulta parametrizada (prepared statements).

• Prevenção: usar parâmetros (bind variables), evitar concatenação de strings, validar entrada, usar contas de banco com menor privilégio.
• Complementos: ORM ajuda, mas não é garantia; ainda é preciso parametrizar corretamente e validar.

// Exemplo conceitual (NÃO fazer):
SELECT * FROM clientes WHERE cpf = '" + cpf + "';

// Correto (conceitual):
SELECT * FROM clientes WHERE cpf = ?;

Interpretação de requisições/respostas e seleção de boas práticas (estilo prova)

Questões de interpretação (analise e responda)

1) Uma requisição retorna 401 Unauthorized. O que isso indica mais provavelmente?

• A) O usuário está autenticado, mas não tem permissão
• B) O token/credencial está ausente, inválido ou expirado
• C) O recurso não existe
• D) O servidor está fora do ar

2) Uma API retorna 403 Forbidden após enviar um token válido. Interpretação mais adequada:

• A) Falha de autenticação
• B) Falha de autorização (escopo/role insuficiente)
• C) Erro de validação de payload
• D) Redirecionamento

3) Em uma criação via POST /clientes, a resposta correta para indicar sucesso e apontar o recurso criado é:

• A) 200 OK com header Set-Cookie
• B) 201 Created com header Location
• C) 204 No Content com body JSON
• D) 304 Not Modified

4) Um endpoint GET /relatorios gera um arquivo e altera um contador de auditoria a cada chamada. Qual afirmação é mais correta?

• A) GET é sempre seguro e não altera estado
• B) GET deveria ser usado, mas não pode ter logs
• C) GET não deveria ter efeitos colaterais relevantes; se altera estado de negócio, o design deve ser revisto
• D) GET é proibido em APIs corporativas

5) Um cliente repete automaticamente uma requisição após timeout. Qual método é mais apropriado para ser repetido com segurança (idempotência)?

• A) POST
• B) PUT
• C) Qualquer um
• D) CONNECT

Seleção de boas práticas (marque a melhor opção)

6) Para mitigar CSRF em aplicações com cookies de sessão, a medida mais diretamente relacionada é:

• A) Parametrizar SQL
• B) Token anti-CSRF e SameSite em cookies
• C) Habilitar CORS para qualquer origem
• D) Retornar 201 em todas as respostas

7) Para mitigar XSS, a prática mais adequada é:

• A) Confiar na validação do navegador
• B) Escapar/encode de saída e aplicar CSP
• C) Usar apenas GET
• D) Remover autenticação

8) Para mitigar SQL Injection, a prática mais cobrada é:

• A) Concatenar strings com cuidado
• B) Usar prepared statements/queries parametrizadas
• C) Aumentar timeout do banco
• D) Desativar logs

9) Em versionamento de API, qual opção tende a ser mais simples e comum em ambientes corporativos?

• A) Versionar por fragmento (#v1)
• B) Versionar na URL (/api/v1/...)
• C) Não versionar
• D) Versionar por cor do tema

10) Em paginação, uma boa prática para evitar abuso e melhorar desempenho é:

• A) Permitir tamanho ilimitado
• B) Definir tamanho máximo e retornar metadados de paginação
• C) Retornar sempre todos os itens
• D) Usar POST para listar