Security

StudyOps uses a Next.js server-side route to request public data from ClinicalTrials.gov and Health Canada and a separate route to deliver non-sensitive business requests by email. It has no authentication, user accounts, database-backed reports, payment processing, public report token, or PHI workflow.

StudyOps is not a clinical system of record and should not be used as one.

• HTTPS is expected to be provided through the hosting platform.
• Source code is version controlled.
• Lint and TypeScript checks are part of the development workflow.
• Application changes undergo repository review.
• Registry inputs are length-limited, encoded, and sent only to fixed public registry endpoints with bounded request timeouts.
• Source failures are isolated and user-facing errors do not expose upstream stack traces or credentials.
• Conversion requests accept only JSON within a conservative size limit and validate, normalize, and length-limit every supported field on the server. Unknown fields and client-supplied recipients are rejected.
• Transactional-email credentials remain server-side. The recipient and Nurenyx sender are fixed by server or relay configuration, the validated submitter address is used only as Reply-To, provider timeouts and rejection are handled without exposing provider responses, and request contents are not written to application logs.
• Conversion abuse friction includes a honeypot, a realistic form-time window, same-origin checks where browser signals are available, client duplicate-submit locking, and best-effort per-instance response reuse. The HostGator relay adds timestamped HMAC authentication, replay rejection, and a small filesystem-backed rate limit. Vercel-wide durable rate limiting and WAF enforcement remain deployment responsibilities.
• Non-sensitive Visibility Audit drafts and the current generated report remain in browser localStorage. The report record is versioned, bounded, and schema-validated before display.
• Report source links are validated before rendering, and share summaries exclude cookies, credentials, and unrelated browser storage.
• Deployment is planned through a dedicated hosting platform.

These statements do not represent penetration testing, a formal audit or certification, regulatory approval, a guarantee of encryption at rest, or a mature formal incident-response program.

Nurenyx is responsible for its application code and configuration. Hosting and infrastructure providers operate their respective platform layers. Users are responsible for the information they choose to submit or retain in their browser.

Security is a shared responsibility, and no system can guarantee absolute security.

Please report a suspected security issue privately to innovations@nurenyx.ai. Do not include sensitive information in your first message.

Provide a concise description and safe reproduction steps where possible. Nurenyx does not offer a public bug-bounty or reward promise at this time.

The following items are future work and are not represented as current capabilities:

• Authentication.
• Authorization.
• Organization and workspace isolation.
• Audit logging.
• Centralized secrets rotation procedures.
• Database security.
• Backup and recovery.
• Incident-response procedures.
• Formal privacy and security review.
• Role-based access control.
• Monitoring and alerting.
• Secure billing integration.

For security questions or private reports, contact innovations@nurenyx.ai.