ZeroPhish is an AI-powered phishing and threat-forensics platform that combines browser-side heuristics, threat intelligence, ML/ONNX analysis, multimodal Gemini reasoning, URL/email inspection, SSRF protection, Redis acceleration, persistent analytics, RBAC, real-time SSE telemetry, and a Chrome MV3 security extension.
Python
2
271 commits
updated Oct 10, 2026
Detect suspicious emails using layered heuristics, machine learning, and AI through a Chrome Side Panel.
Stage: production-oriented security and reliability hardening.
ZeroPhish is a security-focused phishing detection platform built around a three-tier detection cascade, a canonical FastAPI gateway, a Chrome extension, and a Next.js dashboard. The repository includes automated security, reliability, backend, and frontend validation.
Security note: Detection results are signals for investigation. No phishing detector should be treated as infallible.
ZeroPhish is a browser-centric phishing detection platform for Gmail. The Chrome extension captures email context and presents the result through a Side Panel while the FastAPI gateway orchestrates layered analysis.
Gmail
│
▼
Chrome Extension
│
│ Email context
▼
FastAPI Gateway :8001
│
├── Tier 1 — Deterministic heuristics
├── Tier 2 — URL / domain / ML analysis
└── Tier 3 — Contextual AI analysis
│
▼
Final assessment
│
├──────────────► SSE
│
▼
Next.js Dashboard
The architecture deliberately avoids making one model or one external provider the sole detection authority.
Phishing messages can combine deceptive URLs, impersonated domains, social engineering, redirects, suspicious infrastructure, and obfuscated or AI-generated content.
ZeroPhish therefore treats email content, URLs, redirect targets, remote responses, uploaded messages, external intelligence, and AI inputs as untrusted data. Detection is performed through multiple layers so that deterministic signals and deeper analysis can complement one another.
| Capability | Description |
|---|---|
| Gmail Chrome Extension | Manifest V3 extension with a browser Side Panel workflow |
| Tier 1 Heuristics | Fast deterministic analysis of suspicious email and URL patterns |
| Tier 2 Analysis | URL/domain analysis, metadata, threat indicators, and ML classification |
| Tier 3 AI Analysis | Contextual Gemini analysis when configured and available |
| Three-Tier Cascade | Combines different evidence sources in a single scan flow |
| Real-Time Updates | Server-Sent Events for live scan progress |
| SSRF Protection | Outbound destinations and redirects are validated before access |
| Authentication & RBAC | Protected application routes enforce authentication and role checks |
| Redis Cache | Optional Redis cache with in-memory fallback |
| Persistence | SQL-backed repositories when DATABASE_URL is configured; in-memory otherwise (state does not survive restart in the default configuration) |
| Circuit Breaker | Protects external Tier 3 dependency paths from repeated failures |
| SSE Backpressure | Bounded subscriber queues with slow-consumer handling |
| Background Task Lifecycle | Tracks asynchronous work and bounds shutdown handling |
| Webhook Isolation | Webhook dispatch does not block scan finalization |
| Observability | Health, readiness, metrics, logging, and runtime diagnostics |
The first layer is optimized for fast, explainable signals, including suspicious URL structure, IP-based URLs, urgency indicators, suspicious domains, brand/domain mismatches, and other deterministic phishing indicators implemented by the extension and gateway.
Tier 2 performs deeper analysis such as URL normalization, redirect-aware inspection, domain metadata, threat patterns, and machine-learning classification.
Tier 3 uses Gemini for contextual analysis when configured. It can assess phishing context, social-engineering signals, suspicious intent, and related evidence. Tier 3 output is constrained by the surrounding security and scoring pipeline rather than being treated as an unrestricted authority.
The fused score is computed by Backend/fusion/engine.py, which renormalizes
weights over whichever tiers actually participated in the scan. There is no
single fixed formula; the weight set depends on which tiers produced a result
(ESTABLISHED_PROFILES in that module):
| Participating tiers | T1 | T2 | T3 | Vision |
|---|---|---|---|---|
| T1 + T2 + T3 + Vision | 0.15 | 0.25 | 0.45 | 0.15 |
| T1 + T2 + T3 | 0.20 | 0.30 | 0.50 | — |
| T1 + T2 + Vision (T3 failed/absent) | 0.25 | 0.50 | — | 0.25 |
| T1 + T2 (partial / pre-Tier-3) | 0.40 | 0.60 | — | — |
When a tier fails or is unavailable it is excluded and the remaining weights are
renormalized to sum to 1.0. A failed advisory tier therefore does not dilute the
authoritative signal, and partial_score (T1+T2 only) uses the 0.40/0.60 profile.
ScoringWeights (T1 0.20 / T2 0.30 / T3 0.50) reported by /health is the
configured weighting, i.e. the T1+T2+T3 profile — it is not the computation for
every scan.
The current configured verdict ranges are:
| Score | Verdict |
|---|---|
0–29 | SAFE |
30–69 | SUSPICIOUS |
70–100 | CRITICAL |
| (none) | UNKNOWN — authoritative tiers did not produce a usable result |
UNKNOWN is a distinct outcome, not a synonym for SAFE: it is returned when the
server-authoritative tiers could not evaluate the scan.
These thresholds are application configuration, not calibrated probabilities of maliciousness.
ZeroPhish uses a layered modular-monolith backend with one canonical API gateway.
┌─────────────────┐
│ Chrome Gmail │
│ Extension │
└────────┬────────┘
│
▼
┌────────────────────────┐
│ Backend/gateway.py │
│ Canonical API :8001 │
└───────────┬────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Tier 1 Tier 2 Tier 3
Heuristics URL / Domain / ML Gemini
│ │ │
└──────────────────┼──────────────────┘
▼
Scan Result / SSE
│
▼
Next.js Dashboard
Backend/
├── gateway.py
├── tier_2/
├── tier_3/
├── ml/
├── repositories/
├── infrastructure/
├── security/
├── auth/
├── models/
└── tests/
The repository also contains automated architecture-boundary checks covering important dependency directions between security, repositories, infrastructure, feature routers, and application orchestration.
tier_2/main.py is retained as a deprecated compatibility reference. It is not the supported deployment entrypoint.
Supported gateway:
Backend/gateway.pyon port8001.
Do not build new integrations against the legacy standalone port 8000 service.
ZeroPhish treats external data and remote destinations as untrusted.
Security tooling in the repository includes the configured Gitleaks, Semgrep, dependency, and CodeQL workflows where enabled by the current CI configuration.
The Manifest V3 extension provides the Gmail integration and Side Panel workflow. It performs browser-side Tier 1 analysis and communicates with the canonical backend gateway.
Current extension permissions include the capabilities required for the product workflow, such as:
activeTabsidePanelstoragescriptingHost access is intentionally constrained rather than granting unrestricted access to arbitrary websites.
Primary technologies include:
Canonical entrypoint:
Backend/gateway.py
Canonical development port:
8001
The dashboard uses Next.js, React, TypeScript, and Server-Sent Events to visualize scan state and results.
ZeroPhish/
├── Backend/
│ ├── gateway.py
│ ├── tier_2/
│ ├── tier_3/
│ ├── ml/
│ ├── repositories/
│ ├── infrastructure/
│ ├── security/
│ ├── auth/
│ ├── models/
│ └── tests/
├── Frontend/
├── extension/
├── scripts/
├── docs/
├── LICENSE
└── README.md
Detailed engineering documentation is indexed in docs/INDEX.md.
git clone https://github.com/Sarvadnya07/ZeroPhish.git
cd ZeroPhish
py -3.13 -m venv .venv
.\.venv\Scripts\Activate.ps1
Copy-Item Backend\.env.example Backend\.env
pip install -r Backend\requirements.txt
python3.13 -m venv .venv
source .venv/bin/activate
cp Backend/.env.example Backend/.env
pip install -r Backend/requirements.txt
Edit Backend/.env for your environment.
cd Backend
python gateway.py
The canonical gateway is:
http://127.0.0.1:8001
Verify it with:
curl http://127.0.0.1:8001/health
In another terminal:
cd Frontend
pnpm install
pnpm dev
chrome://extensions/.extension/ directory.The primary backend template is:
Backend/.env.example
Important configuration areas include:
| Variable | Purpose |
|---|---|
DATABASE_URL | Persistent database configuration |
REDIS_URL | Redis cache and supported shared state |
GEMINI_API_KEY | Gemini Tier 3 configuration |
ENV | Runtime environment |
| Metrics settings | Prometheus-compatible runtime metrics |
| OpenTelemetry settings | Optional tracing |
Never commit API keys, credentials, or .env files.
The supported API is exposed through Backend/gateway.py on port 8001.
| Method | Endpoint | Purpose |
|---|---|---|
POST | /gateway/scan | Submit an email for analysis |
GET | /gateway/status/{scan_id} | Retrieve scan status |
GET | /gateway/result/{scan_id} | Retrieve a completed result |
GET | /gateway/health | Gateway health information |
POST | /vision/analyze | Vision analysis |
GET | /auth/me | Authentication context |
POST | /email/scan-eml | Analyze a raw .eml message |
GET | /analytics/threat-feed | Threat-feed information |
GET | /cache/stats | Cache statistics |
DELETE | /cache/clear | Clear cached scan reports |
curl -X POST http://127.0.0.1:8001/gateway/scan \
-H "Content-Type: application/json" \
-d '{
"sender": "[email protected]",
"subject": "URGENT: Verify your account now",
"body": "Your account has been suspended. Verify your credentials immediately.",
"links": [
"http://192.168.1.1/verify",
"http://paypa1.com/secure"
],
"tier1_score": 72,
"tier1_evidence": [
"Urgency keyword",
"IP-based URL",
"Brand mismatch"
]
}'
A completed response contains the scan identifier, tier results, evidence, score, verdict, completion state, and cache state where applicable.
Webhook events can include:
scan.completescan.criticalscan.suspiciousWebhook dispatch is asynchronous so slow or unavailable receivers do not block scan finalization.
Webhook delivery is currently best-effort / at-most-once.
A gateway restart or process failure between scan finalization and background dispatch can lose an event. The current implementation does not provide a durable delivery ledger or transactional outbox.
The persisted scan result is the authoritative record.
Durable webhook delivery and guaranteed retry behavior are not represented as implemented functionality unless the current repository adds those guarantees.
The reliability layer focuses on controlled failure behavior and recovery.
The Tier 3 dependency path uses circuit-breaker behavior to reduce repeated calls while an external dependency is failing.
CLOSED
│ repeated failures
▼
OPEN
│ recovery timeout
▼
HALF_OPEN
│
├── success ──► CLOSED
└── failure ──► OPEN
Distributed state behavior depends on the configured shared-state mechanism. Process-local behavior remains relevant to the deployment model.
Subscriber queues are bounded and support backpressure handling so slow consumers do not cause unbounded queue growth.
Asynchronous tasks are tracked so application shutdown can cancel and drain active work within a bounded shutdown window.
ZeroPhish currently favors explicit state ownership over assuming automatic horizontal scalability.
The simplest deployment keeps application and SSE subscriber state in one gateway process.
Configure the database and Redis integrations when durable persistence and cache-backed operation are required.
Multi-instance deployment requires explicit treatment of shared state:
Adding more gateway processes does not by itself make SSE state distributed.
Current observability surfaces include:
Typical operational endpoints include:
/health
/ready
/metrics
Exact availability depends on runtime configuration.
The extension is a Manifest V3 application.
chrome://extensions/.After changing extension files, reload the extension from the Chrome extensions page.
The extension uses the repository's current vanilla JavaScript extension structure and does not require a conventional application build pipeline.
ZeroPhish uses multiple verification layers:
Unit Tests
│
▼
Integration Tests
│
▼
Runtime / Network Verification
│
▼
Deployment / Staging Verification
python -m pytest Backend/tests/
cd Frontend
pnpm test
npx tsc --noEmit
pnpm build
powershell -File scripts/security-gate.ps1
The repository separates mocked/unit evidence from runtime and network evidence. A passing unit test is not treated as proof of distributed production behavior.
Windows:
netstat -ano | findstr :8001
taskkill /PID <PID> /F
The supported gateway port is 8001. Port 8000 is the deprecated standalone Tier 2 entrypoint.
Redis is optional for configurations that support the cache fallback. When Redis is required, verify that the configured REDIS_URL is reachable.
When Tier 3 is required, configure the Gemini credentials in the backend environment. Never commit the key.
Check manifest.json and the service-worker/content-script consoles in Chrome DevTools.
Windows PowerShell:
Remove-Item -Recurse -Force node_modules
pnpm install
pnpm test
pnpm build
Use a clean virtual environment:
py -3.13 -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r Backend\requirements.txt
pip check
Detailed engineering documentation is maintained under docs/.
Start with docs/INDEX.md, then use the relevant architecture, testing, reliability, security, deployment, and operations documents.
Contributions should preserve the project's security and reliability boundaries.
git checkout -b feature/your-change
Before opening a pull request, run the relevant validation:
python -m pytest Backend/tests/
cd Frontend
pnpm test
npx tsc --noEmit
pnpm build
For security-sensitive changes:
powershell -File scripts/security-gate.ps1
Pull requests should include appropriate tests and documentation, avoid unnecessary permissions, and contain no secrets or credentials.
ZeroPhish is released under the MIT License.
ZeroPhish — security-focused phishing detection for the browser.
Built with Python, FastAPI, Next.js, Chrome APIs, machine learning, and AI.
ZeroPhish is an AI-powered phishing and threat-forensics platform that combines browser-side heuristics, threat intelligence, ML/ONNX analysis, multimodal Gemini reasoning, URL/email inspection, SSRF protection, Redis acceleration, persistent analytics, RBAC, real-time SSE telemetry, and a Chrome MV3 security extension.
Python
2
271 commits
updated Oct 10, 2026
Detect suspicious emails using layered heuristics, machine learning, and AI through a Chrome Side Panel.
Stage: production-oriented security and reliability hardening.
ZeroPhish is a security-focused phishing detection platform built around a three-tier detection cascade, a canonical FastAPI gateway, a Chrome extension, and a Next.js dashboard. The repository includes automated security, reliability, backend, and frontend validation.
Security note: Detection results are signals for investigation. No phishing detector should be treated as infallible.
ZeroPhish is a browser-centric phishing detection platform for Gmail. The Chrome extension captures email context and presents the result through a Side Panel while the FastAPI gateway orchestrates layered analysis.
Gmail
│
▼
Chrome Extension
│
│ Email context
▼
FastAPI Gateway :8001
│
├── Tier 1 — Deterministic heuristics
├── Tier 2 — URL / domain / ML analysis
└── Tier 3 — Contextual AI analysis
│
▼
Final assessment
│
├──────────────► SSE
│
▼
Next.js Dashboard
The architecture deliberately avoids making one model or one external provider the sole detection authority.
Phishing messages can combine deceptive URLs, impersonated domains, social engineering, redirects, suspicious infrastructure, and obfuscated or AI-generated content.
ZeroPhish therefore treats email content, URLs, redirect targets, remote responses, uploaded messages, external intelligence, and AI inputs as untrusted data. Detection is performed through multiple layers so that deterministic signals and deeper analysis can complement one another.
| Capability | Description |
|---|---|
| Gmail Chrome Extension | Manifest V3 extension with a browser Side Panel workflow |
| Tier 1 Heuristics | Fast deterministic analysis of suspicious email and URL patterns |
| Tier 2 Analysis | URL/domain analysis, metadata, threat indicators, and ML classification |
| Tier 3 AI Analysis | Contextual Gemini analysis when configured and available |
| Three-Tier Cascade | Combines different evidence sources in a single scan flow |
| Real-Time Updates | Server-Sent Events for live scan progress |
| SSRF Protection | Outbound destinations and redirects are validated before access |
| Authentication & RBAC | Protected application routes enforce authentication and role checks |
| Redis Cache | Optional Redis cache with in-memory fallback |
| Persistence | SQL-backed repositories when DATABASE_URL is configured; in-memory otherwise (state does not survive restart in the default configuration) |
| Circuit Breaker | Protects external Tier 3 dependency paths from repeated failures |
| SSE Backpressure | Bounded subscriber queues with slow-consumer handling |
| Background Task Lifecycle | Tracks asynchronous work and bounds shutdown handling |
| Webhook Isolation | Webhook dispatch does not block scan finalization |
| Observability | Health, readiness, metrics, logging, and runtime diagnostics |
The first layer is optimized for fast, explainable signals, including suspicious URL structure, IP-based URLs, urgency indicators, suspicious domains, brand/domain mismatches, and other deterministic phishing indicators implemented by the extension and gateway.
Tier 2 performs deeper analysis such as URL normalization, redirect-aware inspection, domain metadata, threat patterns, and machine-learning classification.
Tier 3 uses Gemini for contextual analysis when configured. It can assess phishing context, social-engineering signals, suspicious intent, and related evidence. Tier 3 output is constrained by the surrounding security and scoring pipeline rather than being treated as an unrestricted authority.
The fused score is computed by Backend/fusion/engine.py, which renormalizes
weights over whichever tiers actually participated in the scan. There is no
single fixed formula; the weight set depends on which tiers produced a result
(ESTABLISHED_PROFILES in that module):
| Participating tiers | T1 | T2 | T3 | Vision |
|---|---|---|---|---|
| T1 + T2 + T3 + Vision | 0.15 | 0.25 | 0.45 | 0.15 |
| T1 + T2 + T3 | 0.20 | 0.30 | 0.50 | — |
| T1 + T2 + Vision (T3 failed/absent) | 0.25 | 0.50 | — | 0.25 |
| T1 + T2 (partial / pre-Tier-3) | 0.40 | 0.60 | — | — |
When a tier fails or is unavailable it is excluded and the remaining weights are
renormalized to sum to 1.0. A failed advisory tier therefore does not dilute the
authoritative signal, and partial_score (T1+T2 only) uses the 0.40/0.60 profile.
ScoringWeights (T1 0.20 / T2 0.30 / T3 0.50) reported by /health is the
configured weighting, i.e. the T1+T2+T3 profile — it is not the computation for
every scan.
The current configured verdict ranges are:
| Score | Verdict |
|---|---|
0–29 | SAFE |
30–69 | SUSPICIOUS |
70–100 | CRITICAL |
| (none) | UNKNOWN — authoritative tiers did not produce a usable result |
UNKNOWN is a distinct outcome, not a synonym for SAFE: it is returned when the
server-authoritative tiers could not evaluate the scan.
These thresholds are application configuration, not calibrated probabilities of maliciousness.
ZeroPhish uses a layered modular-monolith backend with one canonical API gateway.
┌─────────────────┐
│ Chrome Gmail │
│ Extension │
└────────┬────────┘
│
▼
┌────────────────────────┐
│ Backend/gateway.py │
│ Canonical API :8001 │
└───────────┬────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Tier 1 Tier 2 Tier 3
Heuristics URL / Domain / ML Gemini
│ │ │
└──────────────────┼──────────────────┘
▼
Scan Result / SSE
│
▼
Next.js Dashboard
Backend/
├── gateway.py
├── tier_2/
├── tier_3/
├── ml/
├── repositories/
├── infrastructure/
├── security/
├── auth/
├── models/
└── tests/
The repository also contains automated architecture-boundary checks covering important dependency directions between security, repositories, infrastructure, feature routers, and application orchestration.
tier_2/main.py is retained as a deprecated compatibility reference. It is not the supported deployment entrypoint.
Supported gateway:
Backend/gateway.pyon port8001.
Do not build new integrations against the legacy standalone port 8000 service.
ZeroPhish treats external data and remote destinations as untrusted.
Security tooling in the repository includes the configured Gitleaks, Semgrep, dependency, and CodeQL workflows where enabled by the current CI configuration.
The Manifest V3 extension provides the Gmail integration and Side Panel workflow. It performs browser-side Tier 1 analysis and communicates with the canonical backend gateway.
Current extension permissions include the capabilities required for the product workflow, such as:
activeTabsidePanelstoragescriptingHost access is intentionally constrained rather than granting unrestricted access to arbitrary websites.
Primary technologies include:
Canonical entrypoint:
Backend/gateway.py
Canonical development port:
8001
The dashboard uses Next.js, React, TypeScript, and Server-Sent Events to visualize scan state and results.
ZeroPhish/
├── Backend/
│ ├── gateway.py
│ ├── tier_2/
│ ├── tier_3/
│ ├── ml/
│ ├── repositories/
│ ├── infrastructure/
│ ├── security/
│ ├── auth/
│ ├── models/
│ └── tests/
├── Frontend/
├── extension/
├── scripts/
├── docs/
├── LICENSE
└── README.md
Detailed engineering documentation is indexed in docs/INDEX.md.
git clone https://github.com/Sarvadnya07/ZeroPhish.git
cd ZeroPhish
py -3.13 -m venv .venv
.\.venv\Scripts\Activate.ps1
Copy-Item Backend\.env.example Backend\.env
pip install -r Backend\requirements.txt
python3.13 -m venv .venv
source .venv/bin/activate
cp Backend/.env.example Backend/.env
pip install -r Backend/requirements.txt
Edit Backend/.env for your environment.
cd Backend
python gateway.py
The canonical gateway is:
http://127.0.0.1:8001
Verify it with:
curl http://127.0.0.1:8001/health
In another terminal:
cd Frontend
pnpm install
pnpm dev
chrome://extensions/.extension/ directory.The primary backend template is:
Backend/.env.example
Important configuration areas include:
| Variable | Purpose |
|---|---|
DATABASE_URL | Persistent database configuration |
REDIS_URL | Redis cache and supported shared state |
GEMINI_API_KEY | Gemini Tier 3 configuration |
ENV | Runtime environment |
| Metrics settings | Prometheus-compatible runtime metrics |
| OpenTelemetry settings | Optional tracing |
Never commit API keys, credentials, or .env files.
The supported API is exposed through Backend/gateway.py on port 8001.
| Method | Endpoint | Purpose |
|---|---|---|
POST | /gateway/scan | Submit an email for analysis |
GET | /gateway/status/{scan_id} | Retrieve scan status |
GET | /gateway/result/{scan_id} | Retrieve a completed result |
GET | /gateway/health | Gateway health information |
POST | /vision/analyze | Vision analysis |
GET | /auth/me | Authentication context |
POST | /email/scan-eml | Analyze a raw .eml message |
GET | /analytics/threat-feed | Threat-feed information |
GET | /cache/stats | Cache statistics |
DELETE | /cache/clear | Clear cached scan reports |
curl -X POST http://127.0.0.1:8001/gateway/scan \
-H "Content-Type: application/json" \
-d '{
"sender": "[email protected]",
"subject": "URGENT: Verify your account now",
"body": "Your account has been suspended. Verify your credentials immediately.",
"links": [
"http://192.168.1.1/verify",
"http://paypa1.com/secure"
],
"tier1_score": 72,
"tier1_evidence": [
"Urgency keyword",
"IP-based URL",
"Brand mismatch"
]
}'
A completed response contains the scan identifier, tier results, evidence, score, verdict, completion state, and cache state where applicable.
Webhook events can include:
scan.completescan.criticalscan.suspiciousWebhook dispatch is asynchronous so slow or unavailable receivers do not block scan finalization.
Webhook delivery is currently best-effort / at-most-once.
A gateway restart or process failure between scan finalization and background dispatch can lose an event. The current implementation does not provide a durable delivery ledger or transactional outbox.
The persisted scan result is the authoritative record.
Durable webhook delivery and guaranteed retry behavior are not represented as implemented functionality unless the current repository adds those guarantees.
The reliability layer focuses on controlled failure behavior and recovery.
The Tier 3 dependency path uses circuit-breaker behavior to reduce repeated calls while an external dependency is failing.
CLOSED
│ repeated failures
▼
OPEN
│ recovery timeout
▼
HALF_OPEN
│
├── success ──► CLOSED
└── failure ──► OPEN
Distributed state behavior depends on the configured shared-state mechanism. Process-local behavior remains relevant to the deployment model.
Subscriber queues are bounded and support backpressure handling so slow consumers do not cause unbounded queue growth.
Asynchronous tasks are tracked so application shutdown can cancel and drain active work within a bounded shutdown window.
ZeroPhish currently favors explicit state ownership over assuming automatic horizontal scalability.
The simplest deployment keeps application and SSE subscriber state in one gateway process.
Configure the database and Redis integrations when durable persistence and cache-backed operation are required.
Multi-instance deployment requires explicit treatment of shared state:
Adding more gateway processes does not by itself make SSE state distributed.
Current observability surfaces include:
Typical operational endpoints include:
/health
/ready
/metrics
Exact availability depends on runtime configuration.
The extension is a Manifest V3 application.
chrome://extensions/.After changing extension files, reload the extension from the Chrome extensions page.
The extension uses the repository's current vanilla JavaScript extension structure and does not require a conventional application build pipeline.
ZeroPhish uses multiple verification layers:
Unit Tests
│
▼
Integration Tests
│
▼
Runtime / Network Verification
│
▼
Deployment / Staging Verification
python -m pytest Backend/tests/
cd Frontend
pnpm test
npx tsc --noEmit
pnpm build
powershell -File scripts/security-gate.ps1
The repository separates mocked/unit evidence from runtime and network evidence. A passing unit test is not treated as proof of distributed production behavior.
Windows:
netstat -ano | findstr :8001
taskkill /PID <PID> /F
The supported gateway port is 8001. Port 8000 is the deprecated standalone Tier 2 entrypoint.
Redis is optional for configurations that support the cache fallback. When Redis is required, verify that the configured REDIS_URL is reachable.
When Tier 3 is required, configure the Gemini credentials in the backend environment. Never commit the key.
Check manifest.json and the service-worker/content-script consoles in Chrome DevTools.
Windows PowerShell:
Remove-Item -Recurse -Force node_modules
pnpm install
pnpm test
pnpm build
Use a clean virtual environment:
py -3.13 -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r Backend\requirements.txt
pip check
Detailed engineering documentation is maintained under docs/.
Start with docs/INDEX.md, then use the relevant architecture, testing, reliability, security, deployment, and operations documents.
Contributions should preserve the project's security and reliability boundaries.
git checkout -b feature/your-change
Before opening a pull request, run the relevant validation:
python -m pytest Backend/tests/
cd Frontend
pnpm test
npx tsc --noEmit
pnpm build
For security-sensitive changes:
powershell -File scripts/security-gate.ps1
Pull requests should include appropriate tests and documentation, avoid unnecessary permissions, and contain no secrets or credentials.
ZeroPhish is released under the MIT License.
ZeroPhish — security-focused phishing detection for the browser.
Built with Python, FastAPI, Next.js, Chrome APIs, machine learning, and AI.