Security Overview

Giby Technologies Private Limited takes the security of institutional and personal data on the EduEagle Platform seriously. This document provides an overview of the security architecture, controls, and practices the Company implements to protect data entrusted to the Company.

1. Infrastructure Security

1.1 Data Encryption

• All data in transit is encrypted using HTTPS/TLS (minimum TLS 1.2)
• All API communication between the Next.js frontend and Express backend occurs over HTTPS
• File uploads are transmitted securely to Cloudinary via HTTPS

1.2 Database Security

• MongoDB database access is restricted to authenticated application-layer connections only
• Database credentials are stored as environment variables — never hardcoded in source code
• Mongoose ODM enforces schema validation before any data is written to the database
• All queries are scoped to the institution's collegeId and branchId — cross-tenant data access is structurally impossible

1.3 File Storage

• All user-uploaded files (profile photos, assignment documents, payment proofs) are stored on Cloudinary's enterprise cloud storage
• Temporary local copies created during upload processing are deleted immediately after successful Cloudinary upload
• Cloudinary access is managed via API keys stored in server-side environment variables only

2. Application Security

2.1 Authentication

• Authentication is handled via JSON Web Tokens (JWT) containing user ID, role, collegeId, branchId, and collegeKey
• All API endpoints are protected by the verifyToken() middleware — unauthenticated requests are rejected
• JWT tokens are validated on every request — expired or tampered tokens are rejected
• Passwords are hashed using bcrypt with appropriate cost factor — plaintext passwords are never stored or logged

2.2 Account Lockout

• Three consecutive failed login attempts trigger an account lockout
• The account cannot authenticate until the lockedUntil timestamp has passed
• This lockout is enforced at the authentication service layer — it cannot be bypassed by calling the API directly

2.3 Role-Based Access Control (RBAC)

• Every API route is guarded by the restrictTo(...roles) middleware
• Users can only access data and perform actions permitted by their assigned role
• Role assignments are verified from the JWT on every request — not from client-side input
• The frontend extends role granularity (principal, vice_principal, HOD) for UI control without exposing these to the backend trust boundary

2.4 Input Validation

• All incoming API payloads are validated using Joi schemas before reaching any controller
• Frontend forms use Zod validation aligned with backend schemas
• MongoDB schemas enforce data type and uniqueness constraints at the database level
• File uploads are processed via Multer with type and size restrictions

2.5 Tenant Isolation

• Every database query is filtered by the institution's collegeId and branchId, extracted from the verified JWT
• Central admins who operate across tenants must explicitly pass x-college-id and x-branch-id headers — their actions are fully audit-logged
• The collegeKey acts as a secondary integrity check on bulk operations — guessing an ID alone is insufficient for cross-tenant access

3. Audit Logging

Every administrative action on the Platform is captured in a dedicated AuditLog collection recording:

• The acting user (actor ID and role)
• The action performed (create, update, delete)
• IP address and geographic context
• Browser type and operating system
• A unique request ID for traceability

Audit logs are retained for a minimum of 3 years. They are accessible to centralAdmin and collegeAdmin roles within their respective tenants.

4. Vulnerability Management

• The Company conducts periodic internal security reviews of the codebase
• Third-party dependencies are monitored for known vulnerabilities using standard npm audit tooling
• Security patches are applied on an expedited basis for critical vulnerabilities

5. Incident Response

In the event of a security incident:

• The Company's team will assess the incident within 4 hours of detection
• Affected institutions will be notified within 72 hours of confirmed breach
• The Company will provide a post-incident report detailing the nature of the breach, data affected, and remediation steps
• Where required under Indian law, the appropriate authority will be notified

6. Responsible Disclosure

If you discover a security vulnerability in the EduEagle Platform, the Company asks that you report it responsibly to legal@edueagle.in before any public disclosure. The Company commits to:

• Acknowledge your report within 48 hours
• Investigate and remediate the issue promptly
• Credit you for responsible disclosure (if you wish)

The Company does not pursue legal action against researchers who report vulnerabilities in good faith.

7. Contact