Skip to main content

🔐 Security Policy

Security is a top priority for ChildSafeNet.
This document describes vulnerability reporting, system protections, and recommended secure deployment practices.

Responsible DisclosureSecure ArchitectureProduction Hardening

🏗 Architecture

🧠 AI Training

📊 Evaluation

1. Reporting Security Issues​

Please DO NOT report security vulnerabilities via public GitHub issues.

Instead, report privately via email:

opensource-security@github.com
(or replace with your official security contact email)

What to Include in Your Report​

To help us investigate quickly, please include:

  • Type of issue (e.g., authentication bypass, XSS, privilege escalation)
  • Affected file paths
  • Branch / commit hash
  • Clear reproduction steps
  • Proof of concept (if safe to share)
  • Impact analysis (what could an attacker do?)
  • Suggested mitigation (optional)

2. Response Timeline​

We aim to:

  • Acknowledge report within 48 hours
  • Provide initial assessment within 5 business days
  • Patch critical issues as quickly as possible
  • Coordinate responsible disclosure

3. Security Architecture Overview​

1
Auth

Authentication & Authorization

  • JWT-based authentication
  • Role-based access (Parent / Admin)
  • Protected admin endpoints

2
API

API Protection

  • HTTPS required in production
  • CORS restrictions
  • Input validation
  • Model endpoint protected from direct abuse

3
Data

Data Protection

  • Store minimal browsing metadata
  • Avoid storing full page content
  • Parameterized queries (prevent SQL injection)
  • Password hashing (BCrypt / ASP.NET Identity)

4
Extension

Extension Security

  • Manifest V3 (service worker-based)
  • No secret keys hardcoded in extension
  • Token stored in chrome.storage.local
  • Server-authoritative decisions

5
Model

Model Safety

  • Safe model activation process
  • Fallback model support
  • Quality gate validation before release

4. Threat Model Considerations​

Possible attack surfaces:

  • Unauthorized access to admin endpoints
  • Token theft (JWT misuse)
  • Malicious dataset injection
  • Model poisoning
  • Extension background abuse
  • CORS misconfiguration

Mitigation strategies include:

  • Role validation on every endpoint
  • Admin-only dataset approval
  • Rate limiting scan endpoint
  • Logging all admin actions
  • Versioned model registry with rollback

5. Production Hardening Checklist​

Before deployment:

  • Enforce HTTPS
  • Set secure HTTP headers:
    • Content-Security-Policy
    • X-Content-Type-Options
    • X-Frame-Options
  • Enable rate limiting
  • Validate input size limits
  • Disable debug mode
  • Store secrets in environment variables
  • Restrict database access to API only

6. Responsible Disclosure​

We support responsible disclosure practices.

Researchers who responsibly report valid vulnerabilities will be acknowledged (if desired).

Do not attempt:

  • Denial-of-service attacks
  • Data exfiltration
  • Public disclosure before patch

7. AI-Specific Security​

Because ChildSafeNet uses ML models:

  • Protect training dataset from tampering
  • Require admin approval before training
  • Monitor drift anomalies
  • Avoid automatic deployment without evaluation
  • Log model version used for each scan

Summary​

ChildSafeNet security principles:

  • Least privilege access
  • Audit-first logging
  • Stable retraining (Option Periodic)
  • Safe model deployment
  • Responsible disclosure

If in doubt, report privately first.