Security claims should be traceable to a control

This page separates what the marketing application currently enforces from product controls that still require technical, operational, and contractual verification.

Ask a security question

Implemented in this marketing site

These statements are backed by code in this repository. They do not describe the separate product application unless that application uses the same controls.

Server-only secrets: Resend credentials are validated through a server-only environment module and are never included in browser-safe configuration.
Validated inquiry input: Contact and demo payloads are parsed with Zod before email delivery; expected validation failures return field-level messages.
Low-effort abuse controls: Public forms use a honeypot and a best-effort in-memory rate limit. The limiter resets on cold start and is not described as distributed attack protection.
Defensive HTTP headers: The application configures content-type sniffing protection, strict-origin referrers, frame denial, and a restrictive camera, microphone, and geolocation policy.
Minimal marketing-site data surface: This repository has no marketing database, authentication, file upload, payments, analytics package, or advertising tracker. Inquiry data is sent to the configured email provider.
Provider error isolation: Email delivery uses one server adapter with a timeout and normalized public errors. API credentials and provider responses are not returned to visitors.

Verify before product launch or sensitive-data use

The requirements name these security themes, but no implementation evidence, provider contract, audit report, or operating procedure was supplied. They remain a launch checklist, not a current claim.

Encryption in transit and at rest: Evidence needed: Cipher, key management, scope, and provider evidence.
Authentication and role access: Evidence needed: Session policy, role model, privileged access, and revocation.
Tenant isolation: Evidence needed: Workspace scoping in every data path and administrative boundary.
Backups and recovery: Evidence needed: Frequency, retention, restore testing, and recovery objectives.
Audit history: Evidence needed: Events recorded, tamper resistance, retention, and customer access.
Data retention and deletion: Evidence needed: Customer controls, backups, legal holds, and deletion timelines.
Incident response: Evidence needed: Detection, escalation, customer notification, and post-incident review.
Subprocessors and residency: Evidence needed: Provider list, processing locations, transfer terms, and options.

Certifications not claimed

A security illustration, vendor logo, or generated dashboard is not evidence of an audit. Napdav does not claim these certifications on this website.

SOC 2Not claimed
ISO 27001Not claimed
HIPAANot claimed
PCI DSSNot claimed

Report a security concern

Do not send exploit details, credentials, or sensitive customer data through the general contact form. Use the dedicated address below and include only enough information to establish a safe follow-up channel.

security@napdav.com

No bug-bounty program, response-time commitment, encryption key, or secure-file-transfer channel was supplied, so none is implied here.

Security requirements should be part of the fit decision

Bring your data categories, user roles, retention needs, hosting constraints, and required evidence to a technical conversation before using Napdav with sensitive information.

Contact security