Security & Data Protection

SmartMrk is built on enterprise-grade cloud infrastructure with SOC 2 Type II certified providers. Our architecture employs defense-in-depth principles across every layer:

• Encryption in transit: All connections use TLS 1.2+ with HSTS preloading. HTTP requests are automatically upgraded to HTTPS.
• Encryption at rest: All database storage is encrypted with AES-256. Backups are encrypted and stored in geographically separate regions.
• Edge security: Our platform is served through a global edge network with built-in DDoS protection, rate limiting, and web application firewall (WAF) capabilities.
• Serverless architecture: Our serverless compute model eliminates persistent server state, reducing the attack surface. Each request runs in an isolated execution environment.
• Database isolation: Row Level Security (RLS) policies enforce data access control at the database level, ensuring users can only access their own data regardless of application-layer bugs.

Medical tags contain sensitive health information including allergies, medications, emergency contacts, and physician details. We apply the highest level of protection to this data:

• PIN-protected access: Medical tag owners can protect sensitive sections (physician info, insurance details) behind a PIN. Protected data is stripped server-side before any response reaches the client.
• Constant-time PIN verification: PIN checks use constant-time string comparison to prevent timing attacks that could reveal PIN values character by character.
• Rate-limited PIN attempts: PIN verification is limited to 5 attempts per 15 minutes per IP address to prevent brute-force attacks.
• Server-side data filtering: Protected medical fields (physician details, insurance info) are removed from the response at the server level before HTML is generated. This data never reaches the browser unless the correct PIN is provided.
• No caching of sensitive data: API responses containing personal or medical data are served with Cache-Control: no-store and Pragma: no-cache headers to prevent browser or proxy caching.
• Scan page privacy: Internal fields (owner ID, private notes, NFC serial numbers, batch references) are stripped from all public scan views.

• Secure session management: Sessions use HTTP-only, secure, SameSite cookies that cannot be accessed by JavaScript, preventing cross-site scripting (XSS) session theft.
• OAuth integration: We support secure OAuth 2.0 authentication with PKCE (Proof Key for Code Exchange) to prevent authorization code interception attacks.
• Open redirect protection: OAuth and authentication callbacks validate redirect URLs against an allowlist of known application paths, preventing attackers from redirecting users to malicious sites after login.
• Admin role enforcement: Administrative pages and API endpoints require verified admin role credentials checked at both the middleware and API layers.
• Password security: Passwords are hashed using bcrypt with per-user salts. We never store or log plaintext passwords.

• No card data storage: SmartMrk never stores, processes, or transmits credit card numbers. All payment processing is handled by PCI DSS Level 1 compliant payment processors.
• Webhook signature verification: All payment provider webhook events are cryptographically verified before processing. Events with invalid or missing signatures are rejected.
• Server-side price verification: Product prices are verified server-side from the catalog database during checkout. Client-submitted prices are never trusted.
• Amount verification: After payment capture, the captured amount is verified against the order total to prevent price manipulation attacks.
• Subscription tier verification: Subscription tiers are derived from verified payment plan identifiers, not from user-controllable URL parameters.
• Rate-limited payment endpoints: Payment creation endpoints are rate-limited to prevent abuse and resource exhaustion.

• Input validation: All API inputs are validated using strict schemas with type checking, length limits, and format constraints. Invalid requests are rejected before processing.
• Prototype pollution prevention: Profile data is recursively sanitized to strip dangerous keys (__proto__, constructor, prototype) at all nesting levels.
• Rate limiting: All public API endpoints implement sliding-window rate limiting to prevent brute-force attacks, enumeration, and resource exhaustion.
• Content Security Policy: CSP headers restrict script sources, frame ancestors, form actions, and connection targets to prevent cross-site scripting and clickjacking attacks.
• CORS protection: Cross-Origin Resource Policy and Cross-Origin Opener Policy headers isolate the application from cross-origin attacks.
• HTML injection prevention: All user-supplied content in email templates is HTML-escaped before rendering. URL attributes are sanitized to prevent protocol injection.
• File upload security: Uploaded files are validated for MIME type and size. File extensions are derived from validated MIME types, not from user-supplied filenames, preventing path traversal attacks.

• Data minimization: We only collect data necessary for the service to function. Public scan views expose only the information the tag owner has chosen to make public.
• Anonymous messaging: Finder-to-owner messaging uses anonymous conversation tokens. Finders never learn the tag owner's identity unless the owner chooses to reveal it.
• PII redaction: Personal information from resolved recovery cases is automatically redacted after 90 days.
• Legal hold protection: Active recovery cases place a legal hold on the associated tag, preventing accidental data deletion during active investigations.
• Audit trail: Significant actions (status changes, data access, admin operations) are logged in an immutable audit trail for compliance and incident response.
• Message archival: Old messages are automatically archived after 90 days, reducing the window of exposure for any sensitive information shared in conversations.

• Cryptographic tokens: Recovery cases use 256-bit cryptographically random tokens for finder access, making them computationally infeasible to guess or brute-force.
• Identity separation: Owner and finder identities are kept separate throughout the recovery process. Identity is only revealed when explicitly authorized by each party.
• Dual verification: Both the owner and finder must confirm delivery before a recovery case is marked as verified, preventing fraudulent claims.
• Case expiration: Recovery cases automatically expire after 30 days of inactivity, limiting the window for potential abuse.

• HSTS: Strict Transport Security with a 2-year max-age, subdomain inclusion, and preload list registration.
• X-Frame-Options: Set to DENY to prevent clickjacking attacks.
• X-Content-Type-Options: Set to nosniff to prevent MIME type sniffing.
• Referrer-Policy: Set to strict-origin-when-cross-origin to limit information leakage in referrer headers.
• Permissions-Policy: Restricts access to sensitive browser APIs (camera, microphone, USB, Bluetooth, serial) to prevent abuse.
• Cross-Origin isolation: Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy headers prevent cross-origin attacks.

If you discover a security vulnerability in SmartMrk, we encourage responsible disclosure. Please contact us at security@smartmrk.com with details of the vulnerability. We commit to:

• Acknowledging receipt within 24 hours
• Providing an assessment within 72 hours
• Not pursuing legal action against good-faith security researchers
• Crediting researchers who report valid vulnerabilities (with their permission)

Please do not access, modify, or delete other users' data as part of your research. Test only against your own accounts and tags.