Version 1.0 — Effective upon adoption

OptiFlow OS is a workflow, operations, and HRMS platform that handles sensitive employee data including personal information, attendance records, leave history, bank details, and training records. This document outlines our security posture, vulnerability reporting process, and secure development practices.

We accept reports from security researchers, ethical hackers, and the general public. We commit to:

1. Acknowledging receipt within 24 hours
2. Validating the report within 3 business days
3. Triaging based on severity within 5 business days
4. Releasing a fix per the timeline below
5. Disclosing after the fix is released

• Product version (from frontend/package.json or sidebar)
• Environment (self-hosted / SaaS / development)
• Steps to reproduce with clear screenshots or video
• Impact assessment
• Proof-of-concept code (if applicable)
• Suggested fix (optional)

In scope:

• OptiFlow OS frontend (Vue 3 application)
• Authentication and authorization mechanisms
• API client and service layer
• Data storage and handling
• Session management

Out of scope:

• Third-party dependencies (report to respective maintainers)
• Frappe/Django backend (in development — report separately)
• Physical security
• Social engineering
• Denial-of-service attacks (use responsibly)
• Issues requiring physical access or local privilege escalation already obtained

Report Received
      │
      ▼
  [24h] Acknowledgment sent to reporter
      │
      ▼
  [3 days] Validation & Reproduction
      │
      ├── Valid confirmed → Severity Assessment → CVE Assignment
      │
      └── Invalid/duplicate → Report closed with explanation
               │
               ▼
    [5 days] Triage & Priority Assignment
               │
               ▼
    Patch Development
               │
               ▼
    [Per severity] Internal Testing (QA + Security)
               │
               ▼
    Patch Release (npm version bump)
               │
               ▼
    [Per severity] Public Disclosure (GitHub Advisory)

The JWT is currently stored in localStorage (see frontend/src/api/client.ts:37). This is susceptible to XSS — any injected script can read the token.

Planned migration path:

Current:  localStorage → Bearer header
Target:   httpOnly cookie (set by backend) → automatic cookie-based auth

Why this is acceptable for v0.1:

• No persistent XSS vectors identified in the codebase
• Vue's template compiler provides built-in output encoding
• CSP headers will be added in the next release
• The code explicitly notes this in a comment (client.ts:31-34)

Current (v0.1):

OptiFlow OS implements a three-tier RBAC model with hierarchical permissions:

admin (level 2) ─── Full system access
   │
captain (level 1) ─ Team management, approvals, monitoring
   │
  doer (level 0) ── Task execution, self-service

// Current guard logic (router/index.ts)
1. Route requires auth + not authenticated → redirect to /login
2. Authenticated on public auth page → redirect to role home
3. Role mismatch → redirect to user's role home

• Route guards prevent URL manipulation — a Doer cannot navigate to /admin by typing the URL
• Role mismatch redirect — if authenticated but wrong role, redirect to home
• Feature-level checks — components use canUseFeature() before rendering admin actions
• No client-side role elevation — currentRole is derived from the auth response, not user-modifiable

Bank Details (from types/index.ts:38-43):

interface BankDetails {
  account_holder: string
  account_number: string  // Masked in UI
  ifsc: string
  bank_name: string
}

Current controls:

• Account numbers are masked in mock data (XXXXXXXXXXXX1234)
• No sensitive data is logged in Sentry (Sentry beforeSend sanitizes user context)
• Error tracking throttle prevents data flood
• No PII in error messages

Gaps:

• No encryption at rest for bank details (backend not yet implemented)
• No field-level access control (all roles can see own profile)
• No audit trail for sensitive data access

// from api/client.ts
const client = axios.create({
  baseURL: VITE_API_BASE_URL || 'http://localhost:8000',
  timeout: 15000,
  headers: {
    'Content-Type': 'application/json',
    Accept: 'application/json',
  },
})

All endpoints follow the pattern: /api/method/optiflow.api.{module}.{action}

Endpoint categories:

1. Backend sets csrftoken cookie on first GET request
2. Frontend reads cookie via getCookie('csrftoken')
3. Frontend sends token as X-CSRFToken header on mutating requests
4. Backend validates header matches cookie

• No API keys, database credentials, or encryption keys in client code
• VITE_SENTRY_DSN is public by design (Sentry requires client-side DSN)
• All other secrets are server-side (backend not yet built)

• All protected routes have requiresAuth: true meta tag
• Role-specific routes have role: 'doer' | 'captain' | 'admin'
• Route guard catches unauthenticated access, redirects to /login
• Route guard catches role mismatch, redirects to appropriate home
• Catch-all /login redirect prevents 404 on direct URL access
• Chunk load failures show error page instead of white screen

Rules:

• No production secrets in .env files committed to git
• .env.example contains placeholder values only
• Production secrets injected via CI/CD or container orchestration

• HTTPS enforced (TLS 1.3)
• CSP headers configured
• HSTS header configured
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Referrer-Policy: strict-origin-when-cross-origin
• VITE_ENABLE_MOCK=false
• Sentry DSN configured for error tracking
• Rate limiting enabled on backend
• Database encryption at rest enabled
• Regular security scanning configured

From utils/errorTracking.ts:136-147:

beforeSend(event) {
  // Strip URL query parameters
  if (event.request?.url) {
    const url = new URL(event.request.url)
    event.request.url = `${url.origin}${url.pathname}`
  }
  // Sanitize user info
  if (event.user) {
    event.user = { id: 'sanitized' }
  }
  return event
}

Controls in place:

• Deduplication (5s window)
• Throttle (max 10 identical errors per 30s window)
• Global rate limit (max 50 errors per 60s)
• Buffer size limit (50 entries)
• URL sanitization (removes query params)
• User anonymization (replaces with {id: 'sanitized'})
• No PII in error messages

Gap: URL paths may contain employee IDs (e.g., /doer/tasks/TASK-001). This is logged but not scrubbed. Consider sanitizing path segments that match known patterns (employee IDs, task IDs).

No known critical vulnerabilities in the dependency tree at time of writing.

All pull requests must pass:

• vue-tsc --noEmit — TypeScript type safety
• npm run lint — ESLint static analysis
• npm test — Vitest unit + integration tests
• Security review for any code handling PII, auth, or permissions

// All user inputs validated before sending to API
// Patterns used in the codebase:
- Employee ID: trimmed, normalized (hyphen-insensitive for matching)
- Mobile: 10-digit numeric regex
- OTP: 6-digit numeric
- Password: scored (length, uppercase, lowercase, digit, special)
- Email: standard email format (optional field)

• Vue templates auto-escape content in {{ }} expressions
• v-html is used only in training content viewer — ensure content source is trusted (backend-controlled)
• No direct DOM manipulation that bypasses Vue's template system

• All API calls wrapped in try/catch
• Errors normalized via ServiceError class
• User-facing errors are descriptive but do not leak internals
• Stack traces logged server-side (Sentry), never exposed to users
• Loading / error / empty states required on every page

If you discover a security vulnerability in OptiFlow OS:

1. Do not exploit the vulnerability beyond what's necessary to demonstrate it
2. Do not access, modify, or exfiltrate data beyond the proof-of-concept
3. Do not publicly disclose the vulnerability before we've had reasonable time to fix it
4. Do provide clear, reproducible steps
5. Do allow us time to respond before any disclosure (see timeline)

We will not pursue legal action against security researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, or service disruption
• Report vulnerabilities promptly through our reporting channels
• Do not exploit vulnerabilities beyond what is necessary to demonstrate them
• Do not publicly disclose before our fix is released

We will:

• Acknowledge your report within 24 hours
• Work with you to validate and reproduce the issue
• Keep you informed throughout the remediation process
• Credit you in our security advisories (unless you prefer to remain anonymous)

We maintain a Security Hall of Fame for researchers who report valid vulnerabilities:

• Critical/High: Named acknowledgment in release notes + LinkedIn recommendation
• Medium: Named acknowledgment in release notes
• Low: Anonymous acknowledgment (if desired)

• JWT-based authentication
• Role-based route guards
• Feature-level permission checks
• Session idle timeout (30 min with warning)
• CSRF protection (cookie-based)
• Error tracking with Sentry
• Error deduplication and throttling
• Audit logging for admin actions

• CSP headers (Content-Security-Policy)
• HSTS headers
• X-Content-Type-Options: nosniff
• Migrate auth token from localStorage to httpOnly cookie
• Server-side rate limiting (login, API)
• Server-side input validation
• Password policy enforcement (server-side)
• Account lockout after N failed login attempts
• Session invalidation on backend logout
• SECCOMP/seccomp for sandboxing
• Automated dependency scanning (Dependabot/Renovate)

• Encryption at rest for sensitive fields (bank details, PII)
• Field-level access control
• Audit trail for all data access (not just admin actions)
• 2FA / TOTP support
• SSO / SAML / OIDC integration
• IP-based access restrictions
• Role-based API key management
• Read-only audit user role
• Data export / portability API
• Automated penetration testing
• Bug bounty program

Email security@optiflowos.com with details. We'll acknowledge receipt within 24 hours. See How to Report for full details.

Critical fixes within 7 days, high within 14 days, medium within 30 days, low within 90 days. See the severity timeline.

Data in transit is encrypted via HTTPS in production. Data at rest encryption is a backend responsibility and will be implemented before production launch.

OptiFlow uses role-based access control (RBAC) with 24 granular feature flags across three tiers (Doer, Captain, Admin). Access is enforced at the route level, component level, and planned for the API layer. See Authorization Security.

Currently in localStorage as a JWT. This is an interim approach — we plan to migrate to httpOnly cookies for production. A code comment in api/client.ts:31-34 documents this known gap.

Not yet. SSO/SAML/OIDC and TOTP-based 2FA are on the Phase 3 roadmap.

Currently, there is a 2-second client-side cooldown between login attempts. Server-side rate limiting and account lockout after N failures are planned for v1.0.

All data is accessible via the REST API for export. For self-hosted instances, your data remains on your infrastructure. See Data Protection for retention policies.

OptiFlow OS — Operating System for Indian MSMEs

Copyright © OptiFlow Technologies. All rights reserved.