HAPE APP/LEGAL/SECURITY

HAPE APP / LEGAL

Segurança Digital

Política de segurança do HAPE APP: proteção por camadas, autenticação, banco, segredos, incidentes e divulgação responsável.

LGPD / PRIVACY TERMOS / TERMS SEGURANÇA / SECURITY

SECURITYDEFENSE IN DEPTHPRIVACY BY DESIGN

Segurança Digital.

Política de segurança do HAPE APP: proteção por camadas, autenticação, banco, segredos, incidentes e divulgação responsável.

Segurança por concepção e por padrão

A proteção deve ser considerada desde o desenho da funcionalidade até sua operação, com medidas proporcionais à natureza dos dados e ao risco. Dados de saúde, fotos, credenciais e relatórios exigem proteção reforçada.

Defesa em profundidade

O HAPE adota a estratégia de múltiplas camadas: segurança do navegador, transporte HTTPS, autenticação, autorização, políticas de banco, segregação de privilégios, validação de entrada, proteção de segredos e monitoramento. Nenhuma camada isolada é tratada como suficiente.

Autenticação e recuperação

Login, confirmação de e-mail e recuperação de senha devem usar fluxos oficiais do provedor de autenticação, links HTTPS e tokens de uso limitado. Senhas não devem ser registradas em logs, e-mail ou armazenamento em texto simples.

Autorização e banco de dados

Tabelas que contenham dados de usuários devem usar políticas de autorização adequadas, como Row Level Security quando a arquitetura utilizar Supabase. RPCs e funções devem operar com privilégio mínimo e validar identidade e autorização antes de ler ou alterar dados.

Segredos e chaves

Service-role, tokens privados, chaves administrativas, credenciais de banco e segredos de integração não podem ser enviados ao navegador, incorporados ao APK público ou versionados em repositório público. Apenas chaves explicitamente publicáveis podem existir no cliente.

Transporte e conteúdo seguro

O site deve operar por HTTPS e usar cabeçalhos de segurança compatíveis, incluindo HSTS, Content-Security-Policy, proteção contra framing, nosniff, Referrer-Policy e Permissions-Policy. Conteúdo misto HTTP deve ser evitado.

Validação e antiabuso

Entradas devem ser validadas no cliente e, quando houver backend, novamente no servidor. Honeypot, limitação de tentativas, rate limiting, proteção contra enumeração e bloqueios temporários podem ser aplicados conforme o risco. Validação no navegador não substitui validação no servidor.

Formulário de interesse

O formulário público encaminha dados por HTTPS ao FormSubmit para entrega em hapeapp2026@gmail.com. Não há token privado de e-mail embutido no frontend. O formulário não deve ser usado para dados de saúde, senhas, documentos ou informações financeiras.

Privilégio mínimo e acesso interno

Acesso administrativo deve ser restrito ao mínimo necessário, com contas individuais, autenticação forte e revisão periódica. Credenciais compartilhadas devem ser evitadas. Ambientes de desenvolvimento e produção devem ser segregados quando tecnicamente aplicável.

Logs, auditoria e privacidade

Logs devem registrar eventos necessários à segurança sem armazenar senhas, tokens completos ou conteúdo sensível desnecessário. Registros de incidentes e eventos relevantes devem ter acesso restrito e retenção compatível com a finalidade e a lei.

Backups e recuperação

Quando houver backup de dados pessoais, ele deve receber proteção equivalente ao ambiente principal, com acesso restrito, teste de restauração e política de retenção. Backups obsoletos devem ser eliminados conforme a política aplicável.

Dependências e vulnerabilidades

Bibliotecas, serviços e dependências devem ser inventariados e atualizados. Vulnerabilidades críticas devem receber priorização compatível com risco. Mudanças em autenticação, pagamentos, permissões, banco e rotas legais devem ser testadas antes de produção.

Incidentes e resposta

Incidentes devem gerar contenção, preservação de evidências, análise de escopo, correção e documentação. Quando a Resolução CD/ANPD nº 15/2024 se aplicar, o controlador deve comunicar ANPD e titulares em 3 dias úteis nos casos abrangidos. Outras jurisdições podem impor prazos e destinatários próprios.

Fornecedores e cadeia de tratamento

Provedores de hospedagem, autenticação, banco, e-mail e pagamento devem ser avaliados quanto a segurança, privacidade, permissões, localização de dados, termos e mecanismos de transferência internacional quando aplicáveis.

Responsabilidade do usuário

Usuários devem proteger senha, aparelho, e-mail, relatórios exportados, fotos e arquivos locais; manter sistema atualizado; evitar dispositivos comprometidos; confirmar destinatários antes de compartilhar dados; e comunicar suspeita de acesso indevido.

Divulgação responsável

Pesquisadores podem comunicar vulnerabilidades pelo canal publicado em /.well-known/security.txt. A autorização para reportar falhas não inclui exfiltração de dados, persistência, engenharia social, indisponibilidade deliberada ou acesso além do mínimo necessário para demonstrar o problema.

Sem promessa de invulnerabilidade

Nenhum sistema conectado é absolutamente invulnerável. O HAPE não promete “zero risco” ou “impossível de hackear”; compromete-se com prevenção, minimização, detecção, resposta, correção e melhoria contínua.

Conformidade e revisão

Controles técnicos devem ser revisados quando houver mudança de arquitetura, fornecedor, tipo de dado, mercado ou risco. Políticas escritas só são efetivas quando correspondem às práticas reais de produção.

SECURITYDEFENSE IN DEPTHPRIVACY BY DESIGN

Digital Security.

HAPE APP security policy: layered protection, authentication, database controls, secrets, incidents and responsible disclosure.

Security by design and by default

Protection should be considered from feature design through operation, with safeguards proportional to data sensitivity and risk. Health data, images, credentials and reports require heightened protection.

Defense in depth

HAPE follows a layered approach: browser protections, HTTPS transport, authentication, authorization, database policies, privilege separation, input validation, secret protection and monitoring. No single layer is treated as sufficient.

Authentication and recovery

Sign-in, email confirmation and password recovery should use official authentication-provider flows, HTTPS links and limited-use tokens. Passwords must not be logged, emailed or stored in plain text.

Authorization and database

Tables containing user data should use appropriate authorization controls such as Row Level Security where the architecture uses Supabase. RPCs/functions should apply least privilege and validate identity and authorization before reading or changing data.

Secrets and keys

Service-role credentials, private tokens, administrative keys, database credentials and integration secrets must not be sent to the browser, bundled in the public APK or committed to a public repository. Only explicitly publishable client keys may be present in frontend code.

Secure transport and content

The website should operate over HTTPS and use compatible security headers including HSTS, Content-Security-Policy, frame protection, nosniff, Referrer-Policy and Permissions-Policy. Mixed HTTP content should be avoided.

Validation and abuse prevention

Inputs should be validated client-side and, where a backend exists, again server-side. Honeypots, attempt limits, rate limiting, anti-enumeration and temporary lockouts may be applied based on risk. Browser validation does not replace server validation.

Interest form

The public form sends data over HTTPS to FormSubmit for delivery to hapeapp2026@gmail.com. No private email token is embedded in the frontend. The form must not be used for health data, passwords, identity documents or financial information.

Least privilege and internal access

Administrative access should be limited to what is necessary, with individual accounts, strong authentication and periodic review. Shared credentials should be avoided. Development and production environments should be separated where technically applicable.

Logs, audit and privacy

Logs should capture security-relevant events without storing passwords, full tokens or unnecessary sensitive content. Incident/security records should be access-restricted and retained only as needed for their purpose and legal duties.

Backups and recovery

Where personal-data backups exist, they should receive protection equivalent to the primary environment, restricted access, restoration testing and a retention policy. Obsolete backups should be deleted under the applicable schedule.

Dependencies and vulnerabilities

Libraries, services and dependencies should be inventoried and updated. Critical vulnerabilities should be prioritized according to risk. Changes affecting authentication, payments, permissions, database and legal routes should be tested before production.

Incident response

Incidents should trigger containment, evidence preservation, scope analysis, remediation and documentation. Where Brazilian ANPD Resolution 15/2024 applies, covered incidents require notification to the ANPD and affected data subjects within 3 business days. Other jurisdictions may impose different deadlines and recipients.

Vendors and processing chain

Hosting, authentication, database, email and payment providers should be assessed for security, privacy, permissions, data location, terms and international-transfer mechanisms where applicable.

User responsibility

Users should protect passwords, devices, email accounts, exported reports, photos and local files; keep systems updated; avoid compromised devices; verify recipients before sharing data; and report suspected unauthorized access.

Responsible disclosure

Researchers may report vulnerabilities through /.well-known/security.txt. Permission to report a flaw does not include data exfiltration, persistence, social engineering, deliberate denial of service or access beyond the minimum needed to demonstrate the issue.

No invulnerability promise

No connected system is absolutely invulnerable. HAPE does not promise “zero risk” or “unhackable” operation; the commitment is prevention, minimization, detection, response, remediation and continuous improvement.

Compliance and review

Technical controls should be reviewed when architecture, providers, data categories, markets or risks change. Written policies are effective only when they match real production practices.