This document outlines the security policy for Hackwise 2.0, a national-level SaaS hackathon platform built by Sphere Hive at KVG College of Engineering. We take security seriously and appreciate responsible disclosures from the community.

• Supported Versions
• Reporting a Vulnerability
• Response Timeline
• Security Architecture
• Authentication & Authorization
• API Security
• Database Security
• Payment Security
• Environment Variable Security
• Dependency Security
• Known Patched Vulnerabilities
• Security Best Practices for Contributors
• Disclosure Policy

Only the latest production version of Hackwise 2.0 is actively maintained for security patches.

If you are running a self-hosted fork, please keep all dependencies up to date and follow the guidance in this document.

Please do NOT open a public GitHub Issue for security vulnerabilities.

Instead, report vulnerabilities responsibly through one of the following channels:

To help us triage and fix the issue quickly, please include:

• Description — A clear summary of the vulnerability
• Affected component — Which API route, page, or module is affected
• Steps to reproduce — Minimal, reproducible proof-of-concept (PoC)
• Impact assessment — What an attacker could potentially achieve
• Suggested fix (optional but appreciated)

We will keep you informed throughout the process and credit you in the advisory (unless you prefer to remain anonymous).

Hackwise 2.0 is built on the following security-conscious stack:

• Access is controlled by JWT session tokens stored in HttpOnly cookies (admin_session)
• All /admin/* and /api/admin/* routes are protected by middleware.js
• Unauthenticated requests to admin API routes receive a 401 Unauthorized response
• Unauthenticated page visits are redirected to /admin/login

• Teams authenticate via credentials and receive a JWT stored in HttpOnly cookie (team_session)
• All /dashboard/* and /api/team/* routes are verified via verifyTeamSession()
• Session verification is done server-side in middleware before any route handler executes

• CAs authenticate and receive a JWT stored in HttpOnly cookie (ca_session)
• All /campus-ambassador/* and /api/ca/* routes (except public apply/login endpoints) require valid CA session
• Session verification is done server-side in middleware

// Tokens are verified using jose (JOSE standard - JWS/JWE)
// Never stored in localStorage or sessionStorage
// Always HttpOnly, Secure (in production), SameSite cookies

⚠️ Never expose the JWT_SECRET or ADMIN_PASSWORD environment variables to the client side or commit them to version control.

• All API routes validate required fields before processing
• Missing or invalid fields return 400 Bad Request with descriptive error messages
• Numeric fields are validated with parseInt() / parseFloat() and range-checked

• The accommodation booking API uses a database-level UNIQUE KEY on (team_lead_email, check_in_date) to prevent duplicate bookings
• Application-level pre-checks detect existing records and either update them (for payment retry) or reject with 409 Conflict
• ER_DUP_ENTRY database errors are explicitly caught and handled

• All API routes catch errors and return generic error messages to the client
• Detailed error information (stack traces, SQL errors) is logged server-side only, never sent to the client
• Analytics failures are silently swallowed (200 OK with success: false) to avoid leaking server state

⚠️ Recommendation: Consider adding rate limiting (e.g., via Vercel Edge middleware or upstash/ratelimit) to registration and accommodation booking endpoints to prevent abuse.

All database interactions use parameterized queries via mysql2 to prevent SQL injection:

// ✅ Safe — parameterized
await pool.query(
  'SELECT * FROM `hw-teams` WHERE email = ?',
  [userEmail]
);

// ❌ Unsafe — never done in this codebase
await pool.query(`SELECT * FROM hw-teams WHERE email = '${userEmail}'`);

• Critical tables (hw-accommodation-queries, hw-analytics, hw-visitors, hw-logs) are auto-created using CREATE TABLE IF NOT EXISTS on first access
• This prevents startup race conditions without exposing schema management endpoints publicly

• Database credentials are stored exclusively in environment variables (.env.local / Vercel project settings)
• The connection pool (lib/db.js) uses SSL/TLS in production environments where supported
• ECONNREFUSED errors are caught and return a user-friendly 503 Service Unavailable instead of leaking connection details

• Database user should have least-privilege permissions — only SELECT, INSERT, UPDATE, DELETE on the application's tables
• No DROP, CREATE USER, GRANT, or SUPER privileges should be assigned to the app DB user

Hackwise 2.0 uses Razorpay for accommodation payment processing.

• Razorpay orders are created exclusively on the server via /api/accommodation/create-order
• The RAZORPAY_KEY_SECRET is never exposed to the client
• Only the RAZORPAY_KEY_ID (public key) and order_id are sent to the browser

• All payment callbacks verify the Razorpay HMAC-SHA256 signature before marking a payment as successful
• This prevents forged payment success notifications

• The server validates that Razorpay keys are properly configured (not placeholder values) before processing any order
• Returns 500 with a human-readable error if keys are missing, preventing silent misconfiguration

• Card data is never handled or stored by this application
• All sensitive card processing happens within Razorpay's PCI-DSS compliant infrastructure

The following environment variables contain sensitive secrets and must never be committed to version control:

1. Never commit .env.local or any file containing real secrets
2. The .gitignore must include .env* (excluding .env.example)
3. Use Vercel Environment Variables for production deployments
4. Rotate secrets immediately if accidentally exposed
5. Use separate keys for development and production environments

We use GitHub Dependabot for automated dependency vulnerability scanning. Dependencies are reviewed and patched regularly.

• Critical vulnerabilities: Patched within 7 days
• High severity: Patched within 14 days
• Moderate/Low: Reviewed within 30 days

The following vulnerabilities have been identified and patched in this project:

If you are contributing to this project, please follow these guidelines:

• Never use string interpolation for SQL queries — always use parameterized queries
• Never log sensitive data (passwords, tokens, payment IDs) to the console
• Never expose internal error details to API responses — log server-side, return generic messages to clients
• Validate and sanitize all user inputs on the server side, even if validated on the client
• Use HttpOnly, Secure, and SameSite=Strict flags on all authentication cookies
• Implement least-privilege access — API routes should only access data relevant to the authenticated user's role

• Run npm audit before submitting a PR
• Do not add dependencies with known critical/high vulnerabilities
• Prefer well-maintained packages with recent update histories
• Keep package.json and package-lock.json in sync

• Test with placeholder values in .env.local — never use real production secrets locally unless absolutely necessary
• Add new environment variables to .env.example (with placeholder values) when introducing them
• Never hardcode API keys, passwords, or secrets anywhere in the source code

• Security-sensitive changes (auth, payment, DB schema) require extra review scrutiny
• Reference any related CVEs or security advisories in the PR description

We follow a coordinated disclosure model:

1. Reporter submits vulnerability privately
2. We acknowledge within 48 hours
3. We investigate and develop a fix
4. Reporter is notified when a patch is ready
5. Fix is deployed to production
6. Public advisory is published (crediting the reporter unless anonymity is requested)

We request a minimum 14-day embargo after a patch is ready before public disclosure, to allow all users time to update.

We thank the security researchers and open-source community members who have responsibly disclosed vulnerabilities and helped make Hackwise 2.0 more secure.