> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ghg.gg/llms.txt
> Use this file to discover all available pages before exploring further.

# Severity Levels

> How security scan findings are classified and which severity levels block deployment.

# Security Severity Levels

When your game bundle is scanned, each finding is assigned a severity level. The severity determines whether your game can proceed through the pipeline or is automatically rejected.

## Severity Classification

| Level        | Impact              | Action Taken                                                      |
| ------------ | ------------------- | ----------------------------------------------------------------- |
| **CRITICAL** | Immediate rejection | Game is automatically rejected and does not proceed to deployment |
| **HIGH**     | Recorded            | Finding is logged but does not block progression                  |
| **MEDIUM**   | Recorded            | Finding is logged but does not block progression                  |
| **LOW**      | Recorded            | Finding is logged but does not block progression                  |

## CRITICAL Findings

<Warning>
  Games with **CRITICAL** security findings are automatically rejected and do not proceed to deployment. There is no manual override for CRITICAL findings.
</Warning>

CRITICAL findings indicate usage of explicitly prohibited functionality that poses a direct security or privacy risk. Examples include:

* Usage of any [blocked JavaScript API](/security/blocked-apis) (localStorage, sessionStorage, document.cookie, indexedDB, navigator.sendBeacon, eval, Function constructor)
* Network requests to explicitly blocked domains

## HIGH, MEDIUM, and LOW Findings

Findings at these severity levels are **recorded** for reviewer visibility but **do not block** your game from progressing through the pipeline. Reviewers may still flag concerns during manual review, but your submission will not be automatically rejected.

Examples of non-blocking findings:

* **HIGH** — Patterns that resemble data exfiltration but don't use blocked APIs directly
* **MEDIUM** — Unusual code patterns that warrant manual inspection
* **LOW** — Minor observations or informational notes about code structure

## How This Affects Your Submission

```mermaid theme={null}
graph TD
    A[Bundle Uploaded] --> B[Security Scan]
    B --> C{CRITICAL findings?}
    C -->|Yes| D[❌ Automatically Rejected]
    C -->|No| E{HIGH/MEDIUM/LOW findings?}
    E -->|Yes| F[✅ Findings Recorded — Proceeds to Next Stage]
    E -->|No| G[✅ Clean — Proceeds to Next Stage]
```

## Best Practices

To avoid CRITICAL findings and ensure smooth submission:

1. **Do not use any blocked APIs** — review the [full list of blocked APIs](/security/blocked-apis)
2. **Bundle all assets locally** — do not make external network requests
3. **Avoid dynamic code execution** — no `eval()` or `new Function()`
4. **Test with the platform CSP applied** — see [Local Testing](/csp/local-testing) for instructions

## Related

* [Blocked APIs](/security/blocked-apis) — full list of prohibited JavaScript APIs
* [Blocked Domains](/security/blocked-domains) — network restrictions and allowed domains
* [CSP Policy Reference](/csp/policy-reference) — Content Security Policy enforced at runtime