Security Policy

Document Purpose

This document describes the security policy for the Tripinger project. It explains how to report vulnerabilities, how security issues are handled, and how sensitive data and production environments must be protected. It applies to all code, infrastructure, and documentation in the Tripinger monorepo.

Tripinger stores identity, partner compliance, and financial-adjacent data, and operates a travel marketplace with bookings and payments. Security must therefore be treated as a core product requirement, not a bolt-on concern.

Scope

This policy covers:

All repositories and applications in the Tripinger monorepo: apps/api, apps/web, apps/admin, apps/partner, and shared libraries.
Infrastructure defined in docs/ARCHITECTURE.md, docs/DOCKER.md, docs/ENVIRONMENTS.md, and docs/DEVOPS.md (PostgreSQL, Redis, search, object storage, CI/CD).
Database schemas and migration workflows described in docs/DATABASE.md and docs/database/*.
Integrations with external providers such as PayHere, Stripe, SendGrid, Twilio, OpenAI, Mapbox, and media storage platforms.

It does not replace legal or regulatory requirements; those must be respected in addition to this policy when applicable.

Sensitive Data Categories

The database architecture identifies several categories of sensitive data that require special protection.

Examples include:

User identity and contact data
Email addresses, phone numbers, names, login credentials (password hashes).
Authentication-related records (sessions, tokens, device identifiers).
Partner compliance and KYC-like data
Business registration numbers, licenses, SLTDA-related verification artifacts.
Owner identity documents, insurance and registration for vehicles, guides, and hotels.
Financial-adjacent data
Payment provider references (PayHere, Stripe IDs).
Payout details, banking metadata, reconciliation records.
Any data used to link bookings, payments, and partners for settlement and reporting.
Operational and audit data
Admin activity logs tied to internal actions.
Moderation, compliance, and support actions and history.

Exposure or misuse of any of these categories can cause harm to users, partners, or the business. They must be handled with care in code, logs, and environments.

Reporting Security Vulnerabilities

Tripinger encourages responsible reporting of potential security vulnerabilities. If you believe you have found a security issue, please do not open a public GitHub issue describing it. [web:569][web:575]

How to report

Until dedicated contact details are finalized in the main README.md, use the following approach: [web:569]

Prepare a report that includes:

A clear description of the vulnerability.
Steps to reproduce, including affected routes or API endpoints.
Any proof-of-concept demonstrating the issue.
The potential impact (for example, data exposure, unauthorized access, payment manipulation).

Submit the report via:

GitHub’s private vulnerability reporting feature (Security → “Report a vulnerability”), if enabled for the repository. [web:569][web:571]
Or via the private contact channel specified in the root README.md once it is confirmed.

Mark the report as confidential and avoid sharing details in public channels until the issue has been triaged and a fix is deployed.

What happens next

Maintainers will aim to:

Acknowledge the report promptly.
Investigate and reproduce the issue.
Coordinate a fix, tests, and a safe deployment plan.
Communicate back with you on progress and closure, where possible. [web:567][web:575]

Reporters are asked to refrain from public disclosure until the fix is confirmed, to prevent exploitation. [web:575]

Vulnerability Handling

When a vulnerability is reported or discovered:

Triage

Confirm severity and affected components (API, web, admin, partner, infrastructure).
Identify whether sensitive data, authentication, or payments are involved.

Mitigation and fix

Implement code or configuration changes to remove the vulnerability.
Add tests to prevent regressions.
Consider feature flags or temporary restrictions in admin or partner tools if needed.

Deployment

Apply fixes to dev, staging, and production environments via CI/CD, with priority for production if risk is high.
Coordinate with database migrations or rollback strategies if schema changes are involved.

Post-incident review

Document what happened and how it was fixed (internally).
Identify process or tooling improvements (tests, alerts, access controls).

If a vulnerability affects external providers (for example, PayHere, Stripe, SendGrid), those issues should also be reported to the relevant provider according to their policies. [web:574]

Secure Development Practices

Contributors and maintainers must follow secure coding practices across all modules.

Key guidelines:

Authentication and authorization
Use established patterns for auth flows and role-based access control (RBAC) as described in API and admin docs.
Ensure resource-level authorization (for example, partners only access their own listings and bookings).
Input validation and sanitization
Validate and sanitize input at API boundaries to avoid injection, XSS, or data integrity issues.
Use DTOs, schemas, and validation pipes consistently.
Database and migration safety
Avoid migrations that weaken integrity constraints or expose data.
Preserve historical booking and payment data needed for disputes and audits.
Logging and monitoring
Log operational events, but avoid storing raw sensitive data in logs (for example, full card numbers, raw passwords, personal documents).
Use structured, contextual logs with request IDs for debugging and incident analysis.
Error handling
Return safe error messages to clients without exposing internal details (stack traces, SQL snippets, secrets).
Capture full technical context in logs where appropriate.

Secrets and Configuration Management

ENVIRONMENTS.md and DOCKER.md define environment and container expectations. All secret handling must align with them.

Rules:

Never commit secrets to the repository
.env.example may contain placeholder names, but not real keys.
Use hosting platform secret managers (GitHub Actions secrets, Vercel project env vars, cloud provider secrets).
Separate secrets by environment
Different sets for local, dev, staging, and production.
Production secrets must be tightly controlled, with limited access.
Minimal storage of provider data
Store provider references and metadata, not raw payment instrument data.
Encrypt or hash sensitive identifiers where appropriate.
Safe defaults
Avoid enabling dangerous configuration by default (for example, debug modes in production, open CORS policies).
Document safe configuration in docs/ENVIRONMENTS.md and docs/DEVOPS.md.

Data Protection and Privacy

The database architecture emphasizes minimization and controlled exposure of sensitive data.

Guidelines:

Limit data collection
Only collect data needed to deliver core Tripinger features (bookings, payments, partner operations, reviews, planning).
Avoid collecting unrelated personal data without clear justification.
Access control
Restrict access to sensitive tables and endpoints by role and environment.
Admin and partner portals must enforce least-privilege access to operational data.
Data in lower environments
Do not copy real production user/partner data into dev or local environments.
Use masked or synthetic data for testing and demos.
Retention and history
Preserve booking, payment, partner verification, and admin action histories where required for disputes and compliance.
Document retention and deletion rules in future audit and support docs (docs/database/15-audit.md, docs/database/14-support.md) when they are defined.

Infrastructure and Deployment Security

DevOps and architecture docs describe infrastructure components and environments. Security must be part of deployment decisions.

Recommendations:

Network and firewall controls
Limit public exposure of internal services (databases, Redis, search).
Use appropriate firewalls, security groups, or VPCs for backend services.
TLS and secure transport
Use HTTPS for all public-facing endpoints (web, API).
Secure connections to databases, caches, and providers where supported.
Container and image hygiene
Use maintained base images, pinned versions, and regular updates.
Avoid running containers as root where possible.
CI/CD safety
Restrict which branches and workflows can deploy to production.
Ensure CI secrets cannot be exfiltrated via pull requests or forks.
Backups and recovery
Implement automated backups and restore procedures for production PostgreSQL and key infrastructure.
Test recovery processes periodically, as described in future Phase 3 ops docs.

Relationship to Other Documents

This security policy works together with:

docs/DATABASE.md and docs/database/* for data architecture, ownership, and migration strategy.
docs/ENVIRONMENTS.md for environment separation and configuration.
docs/DEVOPS.md for CI/CD, deployments, and operational practices.
CONTRIBUTING.md and CODE_OF_CONDUCT.md for collaboration and behavioural expectations.

When in doubt, security, privacy, and user/partner safety take precedence over convenience and speed.

Policy Evolution

This SECURITY.md file is part of Tripinger’s Phase 1 foundation. As the platform grows, legal requirements, third-party audits, or new features may require updates.

Future versions may:

Add more detailed incident-response procedures.
Clarify regulatory obligations for data retention and processing.
Define specific SLAs for vulnerability response.

Contributors and maintainers are responsible for staying up to date with the latest version and applying its guidance consistently.

Security Policy

On this page