DEV Community: Bryan Rafael

CI de segurança em 10 minutos: workflows prontos (audit semanal + SBOM + secret scan)

Bryan Rafael — Sat, 05 Sep 2026 07:26:04 +0000

Segurança em CI é daquelas coisas que todo mundo concorda que é necessário mas ninguém tem pronto. Em vez de montar do zero, aqui vão 3 workflows que você copia para .github/workflows/ e ajusta uma URL.

1. Auditoria passiva semanal (headers/TLS/CORS/expostos)

name: Security audit semanal
on:
  schedule: [{ cron: "0 8 * * 1" }]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: bryanrafaelbueno/reconpp-action@main
        with:
          url: "https://SEU-SITE.com"

Gera relatório Markdown por site com severidade + correção — a cada segunda-feira você vê a evolução da postura.

2. SBOM e dependências

name: SBOM
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm audit --audit-level=high || true
      - run: pip install pip-audit && pip-audit || true

3. Secret scan

- name: Secret scan
  run: |
    docker run --rm -v "$PWD:/code" \
      trufflesecurity/trufflehog:latest filesystem /code --fail=yes || true

Isso pega chaves e credenciais commitadas antes de virar incidente.

Por que passivo importa

O audit semanal usa só leitura de cabeçalhos — sem fuzzing, sem brute force. Não vai derrubar site nem alertar seu SRE à toa. É a primeira camada que qualquer auditoria profissional verifica.

Os três workflows juntos (com os detalhes de licença e variáveis) estão no meu CI Security Kit — prontos, comentados e com o fluxo de auditoria incluído:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Ferramenta grátis: https://bryanrafaelbueno.github.io/audit-br-store/header-checker.html

Segurança boa é a que roda em todo push. 🛡️

Como transformar uma auditoria passiva em um plano de ação em 30 minutos

Bryan Rafael — Sat, 05 Sep 2026 06:59:27 +0000

Você rodou a auditoria passiva (ex.: o reconpp) e o relatório veio cheio de achados. Para onde olhar primeiro? Este é o caminho de 30 minutos que uso para transformar o relatório em ação.

1. Separe por severidade (5 min)

Severidade	Exemplo típico	Prazo
Alta	RCE, SQLi, IDOR financeiro	72h ou quarentena
Média	XSS armazenado, SSRF limitada	< 14 dias
Baixa	CSP faltando, headers fracos	< 60 dias
Info	Server header, sem security.txt	próximo ciclo

2. Identifique os quick wins (10 min)

Coisas que se resolvem em minutos no orquestrador/servidor:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Cookie flags: Secure; HttpOnly; SameSite=Lax
security.txt (RFC 9116)

3. Monte o plano (10 min)

Hoje: todos os quick wins (30 min de trabalho).
Esta semana: CSP estrito (migre com nonces), 401/403 em arquivos expostos, remova fingerprinting.
Próximos 14 dias: rate limiting, erros genéricos, revisar auth/OAuth.
Próximos 60 dias: dependências no CI, secrets no CI, SBOM.

4. Documente como código

Coloque os headers num config-as-code (nginx/CI/CD) — não numa caixa de comentários. Se não houver CI, o checklist vira lista de issue do projeto.

Esse é exatamente o fluxo que o meu ebook "Web Security Audit na Prática" ensina com o modelo de relatório e a matriz de priorização. Se quiser levá-lo para o seu fluxo, além do ebook (R$49,90) existe o Kit de Auditoria (R$39,90) com a matriz editável e o modelo de relatório em Word:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Amostra grátis: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Auditorias sempre com autorização escrita — mesmo quando passivas. 🛡️

Como conseguir o primeiro emprego como dev no Brasil: currículo, LinkedIn e portfólio (guia rápido)

Bryan Rafael — Sat, 05 Sep 2026 06:51:51 +0000

Não conta os 10 cursos com certificado. Conta o projeto público, a comunicação e o LinkedIn minimamente otimizado. Este é o guia de bolso que usei (e que cobra é mais caro) — organizado em 5 partes.

1. Currículo BR que recrutadores aprovam

1 coluna, máx. 2 páginas. Recrutadores leem ~7 segundos.
Bloco 1: nome + cidade + e-mail + GitHub + LinkedIn.
Bloco 2: título em 1 linha — "Desenvolvedor Python focado em APIs e automação".
Bloco 3: 3 projetos. Formato: nome — o que resolve — stack — link. Projeto com usuário real vale 5x mais.
Bloco 4: formação e cursos (só a ordem superior).
Sem bloco de soft skills nem "objetivo" genérico.

2. LinkedIn em 30 minutos

Capa limpa, foto, título igual ao currículo.
Intro: 2 frases de valor + o que procura.
1 post por semana (progresso de um projeto).
5 conexões/dia com recrutadores + 1 frase personalizada (não pitch).

3. Portfólio que funciona

1 produto com usuário real > 5 clones de tutorial.
Deploy público (GitHub Pages / Vercel/Render) + README detalhado + print/vídeo curto.

4. Entrevistas técnicas

20 LeetCode fáceis/médios/mês + 3 histórias STAR prontas.
Não finja: "ainda não sei, mas sei onde procurar" passa melhor.

5. O ciclo que funciona

20 inscrições/semana (LinkedIn + plataformas + indicações) ≈ 3% de retorno.
Acompanhe tudo numa planilha — meta, não "apliquei quando lembrei".

A parte prática (modelos de mensagem de conexão, textos de intro completo, planilha de candidaturas) está no meu guia em PDF + CSV — se quiser o guia completo e a planilha:

https://bryanrafaelbueno.github.io/emprego-dev/

Também publico ferramentas de segurança em github.com/bryanrafaelbueno. Boa sorte na candidatura! 🚀

SameSite cookies and CSRF: what auditors actually check

Bryan Rafael — Sat, 05 Sep 2026 06:25:48 +0000

CSRF is mostly dead — thanks to SameSite. But "mostly" carries a lot of weight in an audit report: cookies missing SameSite, or set to None without Secure, are the most common session findings.

SameSite, quickly

Value	Cookie sent on	Typical use
`Lax`	Top-level navigations (and same-site) — NOT on subresource requests from other sites	Default for most apps ✓
`Strict`	Same-site requests only	Where you never need external links to carry state
`None`	Always (ignores site) — MUST have `Secure`	Cross-site embed/subdomain auth flows (legacy)

What fails an audit

Cookie without SameSite at all → cross-site state still possible
SameSite=None without Secure → browser rejects the cookie entirely (and the app breaks silently without anyone noticing)
SameSite=None used defensively for everything → CSRF surface recreated
CSRF tokens missing on mutation endpoints that rely only on SameSite (defense-in-depth check)

The passive check

curl -sI https://your-site.com | grep -i set-cookie

reconpp reads every Set-Cookie and reports missing/incorrect flags (Secure, HttpOnly, SameSite) with the exact fix per cookie:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://your-site.com -f md -o report.md

Recommendation

SameSite=Lax by default; Strict for banking-type apps
Keep anti-CSRF tokens anyway (defense in depth)
Never None unless there's a verified cross-site need

The 70+ point checklist (sessions, headers, API, auth, CI/CD) is in the pt-BR ebook — free sample at the store:

Store (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Free sample: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Clickjacking: o que é e como proteger seu site (pt-BR, com verificação automática)

Bryan Rafael — Sat, 05 Sep 2026 06:24:31 +0000

Clickjacking é o ataque em que um site malicioso carrega a sua página dentro de um iframe transparente e engana o usuário para clicar em botões que ele acha que são dele. Duas defesas existem — e uma delas está saindo de cena.

As duas defesas

Mecanismo	Como funciona	Situação
X-Frame-Options: DENY / SAMEORIGIN	Header: navegador recusa carregar em iframe	Legado, ainda suportado
CSP frame-ancestors	Diretiva: `frame-ancestors 'none'` / `'self'` / allowlist	Moderno e mais flexível

Erros que reprovam

X-Frame-Options: ALLOWALL — libera explicitamente o framing (falha direta)
CSP com frame-ancestors * — mesma coisa
Nenhum dos dois — página fica "apertável"
Só XFO quando a página usa widgets de terceiros (empurra você a liberar demais)

Como verificar (passivo)

curl -sI https://seu-site.com | grep -iE "x-frame-options|content-security-policy"

Sem os dois headers (ou com ALLOWALL) a página é frameável. A CLI reconpp marca isso automaticamente com correção sugerida:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://seu-site.com -f md -o relatorio.md

Saída:

[WARN] headers | Clickjacking (X-Frame-Options / frame-ancestors)
Fix: Adicione 'X-Frame-Options: DENY' ou CSP 'frame-ancestors 'none''.

Recomendação

Sistemas novos: só CSP (frame-ancestors 'none')
Legados: mantém XFO até ter CSP válido
Nunca ALLOWALL; allowlist mínima e documentada se o site realmente precisa ser incorporado

Adividade de segurança completa (70+ pontos) no ebook pt-BR — amostra grátis:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Amostra: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

X-Frame-Options vs CSP frame-ancestors: protecting against clickjacking (with a passive check)

Bryan Rafael — Sat, 05 Sep 2026 06:20:14 +0000

Clickjacking is the attack where a malicious site loads your page in a transparent iframe and tricks the victim into clicking buttons they believe belong to the attacker. Two mechanisms stop it — and one of them is being deprecated.

The two defenses

Mechanism	How it works	Status
X-Frame-Options: DENY / SAMEORIGIN	Header: browser refuses to frame the page	Legacy, well supported
CSP frame-ancestors	CSP directive: `frame-ancestors 'none'` / `'self'` / allowlist	Modern, more flexible

What gets it wrong

X-Frame-Options: ALLOWALL — explicitly allows framing; instant FAIL.
CSP with frame-ancestors * — same as ALLOWALL.
Only XFO while adding third-party widgets that need framing (you'll be forced to loosen CSP or drop XFO — do the reverse: keep CSP strict and use allowlists).
Nothing: no XFO + no frame-ancestors = unprotected.

The passive check

Send the request and look for both headers:

curl -sI https://your-site.com | grep -iE "x-frame-options|content-security-policy"

If you see neither (or ALLOWALL), your page is frameable. My CLI reconpp flags this automatically with a suggested fix:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://your-site.com -f md -o report.md

Output shape:

[WARN] headers | Clickjacking (X-Frame-Options / frame-ancestors)
Fix: Add 'X-Frame-Options: DENY' or CSP 'frame-ancestors 'none''.

Recommendation

New systems: CSP only (frame-ancestors 'none'), no XFO.
Legacy: keep XFO until the CSP is enforceable.
Never ALLOWALL; never frame-ancestors * (even for "trusted" embedders, use the explicit allowlist).
If your site is embedded intentially (payment widgets etc.), document it and keep the allowlist minimal.

More pass/fail/repair items in the full 70+ point checklist — free sample at the store:

Store (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Free sample PDF: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Modelo pronto de relatório de pentest (estrutura + template de achado)

Bryan Rafael — Sat, 05 Sep 2026 06:17:05 +0000

O que separa um relatório "amador" de um que cliente respeita não é achar mais bugs — é organizar o que achou. Esta é a estrutura que uso, com o template de achado pronto.

Estrutura de um relatório profissional

Escopo — URLs/hosts, período, objetivo. Também diga o que não foi testado (limitações evitam disputa de expectativa).
Metodologia — passiva/ativa, ferramentas, janela de execução.
Resumo executivo — 5 a 8 linhas para quem decide: total de achados e a proporção por severidade.
Tabela de achados — ID, severidade, título, impacto, afeta.
Detalhamento — um bloco por achado (template abaixo).
Anexos — evidências (request/response), saída de ferramentas, checklist pontuado.

Template de achado (copiar)

ID-01 | Média | Cookie de sessão sem Secure e HttpOnly

Componente: https://cliente.com/login

Descrição:
O cookie de sessão JSESSIONID é emitido sem os atributos Secure e HttpOnly.
- Sem Secure: pode ser interceptado em rede não confiável (downgrade/HTTP).
- Sem HttpOnly: é lido por qualquer XSS, permitindo roubo de sessão.

Evidência (curl -i):
Set-Cookie: JSESSIONID=ABC123; Path=/; HttpOnly  <- sem Secure

Reprodução:
1. POST /login com credenciais válidas
2. Inspecionar o cabeçalho Set-Cookie da resposta
3. Observar ausência de Secure

Correção:
Configurar os atributos no servidor de aplicação:
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.http-only=true
Reteste em 14 dias.

Bibliografia: OWASP Session Management Cheat Sheet.

Regras de evidência

Nunca altere dados de produção para provar; crie dados de teste seus.
Guarde request/response completos (curl -i ou proxy).
Severidade = contexto de negócio: um IDOR em dados financeiros é Média/Alta; em um blog, Informativa.

Gerando o grosso do relatório em 60s

A CLI reconpp produz o relatório de configuração (headers/TLS/cookies/CORS/expostos) já no formato acima, com severidade e correção por achado:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://cliente.com -f md -o relatorio.md

O ebook "Web Security Audit na Prática" traz o checklist 70+, a metodologia em 5 fases e um relatório de exemplo — amostra grátis:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Amostra: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Relatório bom = cliente que contrata o reteste. 🛡️

Tabela de headers de segurança HTTP com valores prontos para copiar (pt-BR)

Bryan Rafael — Sat, 05 Sep 2026 06:14:57 +0000

Guia de bolso dos headers que qualquer auditoria de segurança verifica. Copie, aplique no servidor (nginx/Apache/CDN) e confira com a ferramenta ao final.

Tabela resumo

Header	Valor recomendado	Protege contra
Strict-Transport-Security	`max-age=31536000; includeSubDomains; preload`	downgrade HTTPS→HTTP
Content-Security-Policy	`default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'`	XSS, injeção de conteúdo
X-Content-Type-Options	`nosniff`	MIME sniffing
X-Frame-Options	`DENY` (ou `SAMEORIGIN`)	clickjacking
Referrer-Policy	`strict-origin-when-cross-origin`	vazamento de referrer
Permissions-Policy	`camera=(), microphone=(), geolocation=()`	abuso de APIs do navegador

Nginx de exemplo

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
add_header Referrer-Policy strict-origin-when-cross-origin always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Erros que reprovam em auditoria

HSTS sem includeSubDomains quando há subdomínios
CSP com unsafe-inline e unsafe-eval (anula quase toda a proteção)
X-Frame-Options: ALLOWALL
Cookie sem Secure/HttpOnly/SameSite

Verificando em 60 segundos

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://seu-site.com -f md -o relatorio.md

Cada achado sai com severidade + correção recomendada. A versão completa (checklist 70+ pontos e modelo de relatório) tem amostra grátis:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Amostra: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Coloque os headers primeiro; eles são o "quick win" mais barato de qualquer programa de segurança. 🛡️

security.txt (RFC 9116): o que é, como publicar e como checar em segundos

Bryan Rafael — Sat, 05 Sep 2026 06:08:45 +0000

security.txt (RFC 9116) é um arquivo de texto no seu site que diz quem contatar quando alguém encontrar uma falha. Custou 3 minutos para publicar — e é um dos primeiros itens que qualquer auditor procura.

Como publicar

Crie o arquivo em /.well-known/security.txt:

Contact: mailto:security@suaempresa.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: pt, en
Canonical: https://suaempresa.com/.well-known/security.txt

Regras que reprovam em auditoria:

Expires no passado (sem data futura o arquivo perde validade)
sem Contact: (obrigatório)
caminho errado: /security.txt raiz ajuda, mas o RFC exige /.well-known/security.txt

Checando automaticamente

O reconpp verifica os dois caminhos, além de headers, TLS, cookies, CORS e arquivos expostos:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://suaempresa.com -f md -o relatorio.md

Saída para o bloco well-known:

[PASS] well-known: /.well-known/security.txt | RFC 9116 disclosure contact: present (HTTP 200)
[INFO] well-known: /security.txt | Vulnerability disclosure contact: HTTP 404

Por que isso vende a auditoria?

Empresas que já têm security.txt demonstram maturidade — e o relatório ganha um item verde imediato. Empresas sem o arquivo ganham um "quick win" de 3 minutos que parece um grande avanço no resumo executivo.

O checklist completo de auditoria (70+ pontos) está no ebook pt-BR — amostra grátis na loja:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Amostra: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Modelo pronto: carta de autorização para auditoria de segurança (escopo + regras de engajamento)

Bryan Rafael — Sat, 05 Sep 2026 06:07:53 +0000

Toda auditoria começa por um documento que quase ninguém tem pronto: a autorização por escrito. Sem ela, você não testa — e com ela, o cliente leva a sério. Este é o modelo que uso em auditorias passivas de configuração web.

Modelo de autorização (copiar e adaptar)

TERMO DE AUTORIZAÇÃO DE AUDITORIA DE SEGURANÇA (ESCOPO PASSIVO)

Entre EMPRESA/PESSOA e VOCÊ:

Objetivo: avaliação de configuração de segurança do(s) ativo(s) abaixo, exclusivamente por técnicas passivas (leituras de respostas HTTP normais). Sem fuzzing, sem brute force, sem tentativas de exploração.
Escopo: [URL(s)/domínio(s)/IP(s)] — nada além disso.
Janela: [data início] a [data fim].
Limites: nenhuma modificação de dados; nenhum impacto de disponibilidade; nenhum teste contra terceiros.
Evidências: capturas de requisições/respostas; achados serão reportados só ao Autorizador.
Confidencialidade: achados sob sigilo até correção (prazo sugerido 60 dias).
Autorização: o Autorizador declara ser dono/ter poderes sobre o escopo.

Assinaturas: ____________________ / ____________________

O que anexar

Lista de hosts com owner de cada um
Contatos de emergência (quem avisar se algo estranho aparecer)
Regra de reteste (ex.: 1 reteste gratuito em 14 dias)

Automatizando o escopo passivo

Com o reconpp, o levantamento do bloco A (headers/TLS/cookies/CORS/arquivos expostos) sai em 60 segundos e já gera o relatório com severidades e correções:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://escopo.com -f md -o relatorio.md

O ebook "Web Security Audit na Prática" (pt-BR) traz o checklist completo de 70+ pontos, os modelos de achado e a metodologia em 5 fases — amostra grátis:

Loja (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Amostra grátis: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

Segurança com papel assinado primeiro. Sempre. 🛡️

TLS hardening checklist: expiry, legacy protocols and weak ciphers (passive audit)

Bryan Rafael — Sat, 05 Sep 2026 06:00:06 +0000

You don't need a scanner to catch most TLS failures. A passive review of your certificate chain and protocol negotiation finds the issues clients (and auditors) care about:

What fails a TLS review

Certificate expiring in < 14 days (or already expired). Renewal must be automated — ACME clients are free.
TLS 1.0 / 1.1 still accepted. Legacy protocol support is a fast-track FAIL in any serious audit (PCI-DSS banned TLS 1.0 in 2018).
Weak cipher suites (< 128-bit, RC4, 3DES, CBC beasts). Modern stacks should negotiate AES-GCM/ChaCha20 only.
No HSTS / short max-age: transport security is only as strong as the enforcement header.

Checking without third-party tools

Python's stdlib does all of it:

import ssl
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.check_hostname = False; ctx.verify_mode = ssl.CERT_NONE
for ver in (ssl.TLSVersion.TLSv1, ssl.TLSVersion.TLSv1_1, ssl.TLSVersion.TLSv1_2):
    ctx.minimum_version = ctx.maximum_version = ver
    try:
        with ctx.wrap_socket(connect("yoursite.com", 443), server_hostname="yoursite.com") as s:
            print(ver, "->", s.cipher())
    except Exception:
        print(ver, "-> rejected (good)")

My reconpp CLI packages this (plus cert expiry via ssl._ssl._test_decode_cert, headers, cookies, CORS, exposed files) into one command:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://yoursite.com -f md -o relatorio.md

Baseline to adopt today

HSTS: max-age=31536000; includeSubDomains; preload
TLS 1.2/1.3 only; AES-GCM/ChaCha20 ciphers
Automatic renewal with 30-day buffer (Let's Encrypt + ACME)

The full 70+ point checklist (transport, headers, sessions, API, auth, dependencies, CI/CD) is in my pt-BR ebook — free sample:

Store (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Free sample PDF: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf

CORS misconfigurations: how to audit and fix them (passive checks included)

Bryan Rafael — Sat, 05 Sep 2026 05:29:15 +0000

CORS (Cross-Origin Resource Sharing) is one of the most misunderstood security features. A misconfigured CORS turns a browser into a free data-exfiltration proxy for any site that visits your API. Here's how to audit it passively — no exploits, just reading headers.

The three deadly patterns

Origin reflection: the server echoes Access-Control-Allow-Origin: <whatever the browser sent> instead of an allow-list. Any malicious site can read responses with the victim's cookies (if Access-Control-Allow-Credentials: true).
Wildcard + credentials: Access-Control-Allow-Origin: * combined with credentials is rejected by modern browsers (good), but servers doing reflection with credentials are worse — the browser does accept those.
null origin: sandboxed iframes and some redirects send Origin: null; naive servers allow it.

The passive check

Send a normal GET with a hostile Origin header and inspect the response:

curl -sI -H "Origin: https://evil.example.com" https://api.target.com/me

Findings to flag:

Access-Control-Allow-Origin: https://evil.example.com → FAIL (reflection)
Access-Control-Allow-Credentials: true + reflected origin → FAIL (authenticated data leak)
Access-Control-Allow-Origin: * (no credentials) → WARN (non-authenticated data readable by any origin)

My CLI reconpp runs both probes (Origin: https://evil.example.org and Origin: null) automatically, together with headers/TLS/cookies/сookie checks:

pip install git+https://github.com/bryanrafaelbueno/reconpp
reconpp -u https://api.target.com -f md -o relatorio.md

The fix

Allow-list trusted origins explicitly — never echo the Origin header
Don't use * with credentials; don't reflect null
Vary on Origin when the resource is shared

Full 70+ point audit checklist (headers, TLS, sessions, API, auth, CI/CD) in my pt-BR ebook — free sample at the store:

Store (Pix): https://bryanrafaelbueno.github.io/audit-br-store/
Free sample PDF: https://bryanrafaelbueno.github.io/audit-br-store/sample.pdf