1. Executive Summary: What is a Safe-to-Host Certificate?
A Safe-to-Host Certificate is a mandatory statutory security clearance issued by a CERT-In (Indian Computer Emergency Response Team) Empanelled Information Security Auditing Organization. Under the Guidelines for Indian Government Websites and Apps (GIGW 3.0), no public portal, web application, API, or citizen gateway can be deployed into production or hosted in government data centers (such as NIC, MeghRaj Cloud, or State Data Centres) without an active, unexpired Safe-to-Host certification.
2. The 4-Stage Safe-to-Host Audit Lifecycle
| Phase | Audit Activity | Deliverable |
|---|---|---|
| Stage 1: Pre-Audit Preparation | Freezing application code, configuring staging environment identical to production, setting up audit accounts (admin, user, public). | Signed Scope of Work (SoW) & Architecture Diagram. |
| Stage 2: Primary VAPT Assessment | Automated scanning and manual penetration testing across OWASP Top 10, business logic, SANS 25, and server configuration. | Vulnerability Assessment Report (Level 1) with risk ratings (Critical, High, Medium, Low). |
| Stage 3: Remediation & Patching | Development team patches all Critical, High, and Medium vulnerabilities. Hardening server configs and dependencies. | Remediation Confirmation Document & Updated Codebase. |
| Stage 4: Verification & Clearance | Auditor re-tests all reported findings. If zero Critical/High vulnerabilities remain, certification is granted. | Safe-to-Host Certificate (Valid for 1 year or until major code update). |
3. Pre-Submission Technical Checklist (Self-Audit)
Resolve these common audit failure points before inviting external CERT-In empanelled auditors to accelerate certification:
| # | Audit Focus | Verification Checkpoint | Priority |
|---|---|---|---|
| 01 | SQL Injection (SQLi) | All database operations use parameterized queries or prepared statements; zero raw SQL concatenation. | Critical |
| 02 | Cross-Site Scripting (XSS) | Context-aware output encoding across all templates; inputs sanitized with strict allow-lists. | Critical |
| 03 | Authentication & Sessions | Multi-Factor Authentication (MFA) on admin consoles; session IDs regenerated after login; cookie flags HttpOnly, Secure, SameSite. |
Critical |
| 04 | Access Control (IDOR) | Server-side authorization checks on all record lookups (e.g. /api/user?id=123 must verify caller ownership). |
Critical |
| 05 | Server Information Leakage | Server tokens disabled (ServerTokens Prod, server_tokens off); stack traces suppressed in production. |
High |
| 06 | Security Headers | HSTS, CSP, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy configured on all endpoints. | High |
| 07 | File Upload Security | Uploaded files validated by magic bytes, stored outside web root, given randomized filenames, and directory execution disabled. | Critical |
| 08 | Dependency Scanning | All third-party libraries (npm, composer, pip) scanned for CVEs via Software Bill of Materials (SBOM). | High |
4. Frequently Asked Questions (FAQs)
WebOTG Standards Directorate
WebOTG provides benchmark reference documentation, automated matrix evaluators, and security test harnesses for government digital platforms, WQMS architectures, and STQC compliance frameworks.