DEV Community: Dark Master

I scanned GitLab's source code and found 2,449 undocumented API routes

Dark Master — Sat, 18 Jul 2026 12:29:50 +0000

Last week I pointed a static analysis tool I built at GitLab's public source code. It found 2,449 routes in the actual Ruby code that don't exist anywhere in the official API documentation.

Then I ran it on Mastodon. 601 undocumented routes.

These aren't bugs — they're shadow APIs. Routes that exist, respond to requests, but were never documented. No auth requirements listed. No rate limits specified. No deprecation warnings. Just... there.

What is a shadow API?

A shadow API is any route your server handles that isn't in your OpenAPI/Swagger spec. They appear for a few reasons:

A developer added an internal endpoint and forgot to document it
A route was deprecated but never removed from code
A feature was half-built — routes exist but docs were never written
A framework auto-generates routes (Rails resources, NestJS decorators) and nobody audited what got generated

The problem: your security team can't protect what they don't know exists. Your API gateway can't rate-limit it. Your consumers can't predict when it'll break. And attackers can find it with a directory scan.

How I found 2,449 of them in GitLab

I built a CLI called shadowaudit. It does static analysis — reads your actual framework code, extracts every route, then diffs it against your OpenAPI spec.

npx shadowaudit --dir ./gitlab --spec ./openapi.yaml --framework rails

For GitLab, the scanner:

Parsed every routes.rb and config/routes/*.rb file
Expanded every resources :projects call into its 7 REST routes
Followed every concern :reviewable mounted across multiple resources
Added Grape API routes from lib/api/*.rb — 1,017 routes from that alone
Diffed all detected routes against the public GitLab API spec

Result: 2,449 routes in code with no match in the spec.

Some are intentional internals. Some are legacy. Some are genuinely undocumented public endpoints that clients are probably hitting right now.

The tool: shadowaudit

npm install -g shadowaudit
shadowaudit --dir ./your-api --spec ./openapi.yaml

7 frameworks supported:

Express (including 3-level nested router chains)
Fastify
NestJS (including @Version() decorators)
Koa
Hapi
Rails
Grape

Three modes:

Default — find shadow routes (code not in spec):

shadowaudit --dir . --spec openapi.yaml

CRITICAL  POST   /api/v1/internal/reset      (no auth documented)
HIGH      GET    /api/v2/users/export        (no rate limit documented)
INFO      GET    /health                     (intentionally undocumented)

Reverse mode — find dead spec entries (spec not in code):

shadowaudit --dir . --spec openapi.yaml --reverse

Finds routes your spec documents that no longer exist in code. Dead docs that confuse your consumers.

Coverage scoring — how complete is your OpenAPI spec?

shadowaudit --dir . --spec openapi.yaml --coverage

Coverage Score: 67/100
  Descriptions:    142/200 endpoints  (71%)
  Parameters:      89/134 params      (66%)
  Response codes:  67/200 endpoints   (33.5%)  ← missing 4xx/5xx
  Security:        45/67 endpoints    (67%)

CI integration — fails the build if shadow routes exist:

# .github/workflows/api-audit.yml
- name: Shadow API Audit
  run: npx shadowaudit --dir . --spec openapi.yaml --format markdown >> $GITHUB_STEP_SUMMARY

Exit codes: 0 = clean, 1 = findings, 2 = tool error. CI-safe by design.

Ignore known-good routes:

shadowaudit --dir . --spec openapi.yaml --ignore-paths /health,/metrics,/ping

What makes this different from existing tools

Most shadow API detection tools work at runtime — they watch traffic and flag requests to unknown endpoints. That means:

You need production traffic to find them
You find out AFTER deployment
You need an API gateway or proxy in the path

shadowaudit works at development time, on static code, with zero infrastructure. Run it in CI and catch shadow routes before they ever reach production. No proxy. No traffic. No production access needed.

The closest thing is manually diffing your routes against your spec — which nobody does because it's tedious and breaks every time someone adds a route.

Real-world results

Target	Routes in code	Routes in spec	Shadow routes
GitLab	2,449	~800	~1,649
Mastodon	766	~165	~601

These numbers aren't accusations — both projects are open source and their "shadow" routes are largely intentional internals. But the point stands: even well-maintained APIs with dedicated teams have hundreds of routes that exist outside their documented surface area.

For a smaller team shipping fast, the gap is usually worse.

Try it

# Scan your API against your spec
npx shadowaudit --dir . --spec openapi.yaml

# Add to CI (GitHub Actions)
npx shadowaudit --dir . --spec openapi.yaml --format markdown >> $GITHUB_STEP_SUMMARY

# Score your OpenAPI spec completeness
npx shadowaudit --dir . --spec openapi.yaml --coverage

# Find dead spec entries
npx shadowaudit --dir . --spec openapi.yaml --reverse

npm: shadowaudit (published under darkmaster0345)
GitHub: github.com/darkmaster0345/shadowaudit

It's free. MIT licensed. 459 tests passing across 7 frameworks.

If you find a shadow route you didn't know about — I'd genuinely like to hear about it.

Built this in 8 days as a side project. v1.0.1 shipped yesterday with hardening fixes from an adversarial review — exit code hygiene, Express deep router chain support, NestJS versioning. Feedback welcome.

Tags: security api opensource devops webdev

I Built a Free Shadow API Scanner and Found 269 Forgotten Routes in Ghost CMS

Dark Master — Sun, 12 Jul 2026 18:06:35 +0000

How a weekend project turned into a production tool with 875+ npm downloads in 48 hours — and why your codebase probably has shadow APIs too.

There's a route in your codebase right now that nobody remembers adding.
Maybe a developer spun up app.get('/api/debug/reset') on a Friday to test something. No auth middleware. No documentation. Committed and forgotten. It's been sitting in production for months - invisible to your API scanner, invisible to your security team, visible to anyone who reads your source code.
These are called shadow APIs. And the scary part is: you probably have more of them than you think.
I know because I built a tool to find them, and the results surprised me.

What I built

shadowaudit is a free, open-source CLI tool that scans your source code statically - no agents, no traffic mirrors, no $70K enterprise contracts - and finds API routes that exist in your code but aren't in your OpenAPI spec.
It compares what your code actually does against what your documentation says it does. Any route in the code but not in the spec gets flagged. If that route also has no authentication middleware? That's a CRITICAL finding. Your CI pipeline fails. The PR doesn't merge.
Simple idea. Surprisingly effective.

The Ghost CMS test

To see if shadowaudit actually works on real code (not just toy examples), I ran it against Ghost CMS - the publishing platform that powers 404Media, Platformer, and The Browser. It's a production-grade Express.js app with a large API surface.
The first scan found 269 routes.
But the initial results had problems. Ghost uses a custom auth middleware called mw.authAdminApi that shadowaudit didn't recognize - so 213 routes that actually had auth were reported as "no auth detected." That's a 70% false negative rate. Embarrassing.
So I fixed it. The v0.3.0 update added AST-based auth detection - instead of matching hardcoded pattern strings, it walks the route's arguments in the code's abstract syntax tree and checks if any middleware name contains auth-related words like "auth," "login," "token," "jwt," or "passport."
After the fix: 235 routes correctly authenticated, 0 false positives, 34 routes legitimately public (login, password reset, setup endpoints - expected).
Ghost's security was solid. Zero real vulnerabilities. But the scan proved shadowaudit works on real, production-grade codebases - not just examples.

The features nobody asked for but I built anyway

What started as "compare routes against a spec" grew into a full security tool:
4 framework support. Express.js, FastAPI, Django, and Flask. The tool auto-detects which framework your project uses - just point it at a directory and it figures out the rest.
Three output formats. A colored terminal table for humans. JSON for CI pipelines and jq piping. SARIF 2.1.0 for GitHub's Security tab - findings appear right in your PR with file locations and remediation guidance.
GitHub Action. Published to the GitHub Marketplace. Add 3 lines to your workflow YAML and every pull request gets scanned automatically. A bot posts a findings table directly on the PR as a comment.
Auto-spec generation. Don't have an OpenAPI spec? Run shadowaudit - generate-spec and it creates one from your code. Not perfect - but a starting point.
Mount prefix reconciliation. If you mount routers with app.use('/api/v1', router), shadowaudit figures out that router.get('/users') is actually served at /api/v1/users. This was the hardest feature to build - it required cross-file require tracking and variable name resolution.

The numbers

In 48 hours since the first npm publish:

875+ downloads across all versions
9 releases (v0.1.0-beta through v0.5.1)
113 tests across 13 test files
4 frameworks supported
Socket.dev audit: 100/100 on vulnerability, quality, and license scores
0 open issues (all 5 created and closed)
1 GitHub Marketplace listing
1 documentation site (built with Docusaurus, deployed to GitHub Pages) ## What it looks like

$ npm install -g shadowaudit
$ shadowaudit - dir ./src - spec ./openapi.json
╔══════════════════════════════════════════════╗
║ shadowaudit - Scan Report ║
╚══════════════════════════════════════════════╝
┌──────────┬────────┬───────────────────┬──────┬──────┐
│ SEVERITY │ METHOD │ PATH │ AUTH │ │
├──────────┼────────┼───────────────────┼──────┼──────┤
│ CRITICAL │ GET │ /api/debug/reset │ NO │ │
│ HIGH │ POST │ /api/shadow │ YES │ │
└──────────┴────────┴───────────────────┴──────┴──────┘
⛔ Pipeline will FAIL - 1 critical shadow route(s) detected

That CRITICAL finding? That's the forgotten /api/debug/reset route with no auth. shadowaudit just stopped it from reaching production.

How to use it

# Install
npm install -g shadowaudit
# Scan your code
shadowaudit - dir ./src - spec ./openapi.json
# Don't have a spec? Generate one
shadowaudit - dir ./src - framework express - generate-spec > openapi.json
# Add to GitHub Actions (3 lines)
- uses: darkmaster0345/shadow-Audit@v0.5.1
 with:
 dir: './src'
 spec: './openapi.json'
 fail-on: 'critical'

The honest part

shadowaudit isn't perfect. It has limitations:

Django class-based view methods aren't fully detected (all routes show as GET - fix planned for v0.6.0)
Dynamic route mounting (routes.forEach(route => router.use(route.path, route.route))) isn't supported (too complex for static analysis)
Flask methods= with tuple syntax had a bug in v0.5.0 that was fixed in v0.5.1 (real Flask projects use methods=('GET',) not methods=['GET']) But it's honest about its limitations. Every known issue is documented in the ROADMAP.md. And every release gets a full QA pass before shipping - the v0.5.1 release was driven entirely by bugs found in adversarial QA testing. ##Why I built it Enterprise API security tools (Salt Security, Traceable, Checkmarx) cost $50,000+ per year. They're runtime-based - they watch your traffic and find shadow APIs after they're already deployed and receiving requests. That's reactive. shadowaudit is preventive. It finds the shadow route in the source code before the PR merges, before the endpoint ships, before anyone can send it traffic. And it's free. MIT licensed. No telemetry. No license keys. No phone-home. The only network call is when you use the GitHub Action's PR comment bot, which talks to api.github.com using your own token. ## Try it

npx shadowaudit - dir ./src - framework express
If it finds zero routes - great, you're clean. If it finds a CRITICAL - you just caught a security issue before it reached production.
Either way, it takes 2 seconds and costs nothing.
GitHub: darkmaster0345/shadow-Audit
npm: shadowaudit
Docs: darkmaster0345.github.io/shadow-Audit
- -
If this helped you find a shadow route, consider sponsoring the project. Free tools stay free when people support them.

I built a CLI that catches shadow APIs in Express.js repos before they merge to production

Dark Master — Fri, 10 Jul 2026 11:47:46 +0000

Shadow audit

Static API security scanner — finds undocumented and unauthenticated routes before they reach production

Installation
Global CLI (recommended)
npm install -g shadowaudit
npx (no install needed)
npx shadowaudit --dir ./src --spec ./openapi.json
GitHub Action
Add to .github/workflows/security.yml:

uses: darkmaster0345/shadow-Audit@v0.1.0-beta-2 with: dir: './src' spec: './openapi.json' fail-on: 'critical' The Problem Developers spin up quick test endpoints and forget to remove them. These shadow APIs bypass documentation, skip auth middleware, and get deployed to production silently — invisible to network scanners, invisible to your security team.

Shadowaudit solves this by statically analyzing your codebase, comparing every route definition against your OpenAPI/Swagger spec, and failing your CI pipeline before the PR merges if it finds undocumented or unauthenticated routes.

What Shadowaudit does
Scans your codebase for all actual route definitions (Express.js supported now; FastAPI & Django coming soon)
Compares them against your OpenAPI 3.x / Swagger 2.0 spec
Flags any route missing from the documentation
Detects whether auth middleware is applied to each route
Fails your CI/CD pipeline before the PR merges — with exit codes that respect configurable severity thresholds
Severity levels
Severity Condition CI behavior (--fail-on critical)
CRITICAL Undocumented route + no auth middleware Pipeline fails
HIGH Undocumented route + auth middleware present Pipeline passes (review recommended)
INFO Informational finding Pipeline passes
Supported Frameworks
Express.js ✅ (full support — AST-based route extraction via Babel)
FastAPI 🚧 (coming soon)
Django 🚧 (coming soon)
Installation
npm install -g shadowaudit
Or use it locally in your project:

npm install --save-dev shadowaudit
Quick Start

Scan your codebase against your OpenAPI spec

shadowaudit --dir ./src --spec ./openapi.json

Force a specific framework

shadowaudit --dir ./src --spec ./openapi.json --framework express

Output as JSON (pipe to jq for CI integrations)

shadowaudit --dir ./src --spec ./openapi.json --format json | jq '.findings | length'

Output as SARIF 2.1.0 (for GitHub Code Scanning)

shadowaudit --dir ./src --spec ./openapi.json --format sarif > results.sarif
CLI Options
Usage: shadowaudit [options]

Static API security scanner for undocumented routes

Options:
-V, --version output the version number
--dir Directory to scan (default: current directory)
--spec Path to OpenAPI/Swagger spec file
--format Output format: table, json, sarif (default: "table")
--fail-on Fail CI pipeline on: critical, high, info (default: "critical")
--framework Force framework: express, fastapi, django (default: "auto")
-h, --help display help for command
Exit codes
Condition Exit code
No findings 0
Findings below --fail-on threshold 0
Findings at or above --fail-on threshold 1
--fail-on value Fails when
critical (default) Any CRITICAL finding
high Any CRITICAL or HIGH finding
info Any finding at all
Configuration
shadowaudit loads config from two sources (CLI flags take priority):

CLI flags (highest priority)
.shadowaudit.yml or .shadowauditrc.yml in your project root
Example .shadowaudit.yml:

spec: ./openapi.json
dir: ./src
format: table
failOn: critical
authPatterns:

myCustomAuth
requireLogin ignore:
node_modules
dist
build Default auth patterns (always detected) Even without custom config, shadowaudit detects these auth middleware patterns:

.authenticate( .authorize( requireAuth isAuthenticated
verifyToken checkAuth ensureLoggedIn passport.authenticate
jwt.verify bearerAuth apiKeyAuth basicAuth
Output Formats
Table (default)
Human-readable colored table with severity, method, path, file, line, and auth status. Includes a summary box and pipeline recommendation.

JSON
Structured JSON for CI dashboards and log aggregators:

{
"scanMeta": {
"tool": "shadowaudit",
"version": "0.1.0",
"timestamp": "2026-01-15T12:00:00.000Z",
"stats": { "total": 7, "documented": 5, "undocumented": 2, "critical": 2, "high": 0, "info": 0 }
},
"findings": [
{
"severity": "CRITICAL",
"method": "GET",
"path": "/api/debug/reset",
"file": "routes.js",
"line": 21,
"hasAuth": false,
"reason": "Undocumented route with no authentication middleware detected — publicly accessible shadow API"
}
],
"documentedRoutes": [...]
}
SARIF 2.1.0
Industry-standard format for GitHub Code Scanning, Azure DevOps, and other security dashboards. Maps findings to two rules:

Rule ID Severity Level
SHADOW001 CRITICAL error
SHADOW002 HIGH warning
SHADOW002 INFO note
Demo
Below is the actual terminal output from an end-to-end scan. The test project has 7 Express routes — 5 documented in the OpenAPI spec, 2 undocumented shadow routes with no auth middleware:

[INFO] No config file found, using defaults
╔════════════════════════════════╗
║ shadowaudit v0.1.0 ║
║ API Shadow Route Scanner ║
╚════════════════════════════════╝
[INFO] Directory : /tmp/auth-test
[INFO] Spec file : /tmp/auth-test/openapi.json
[INFO] Format : table
[INFO] Fail on : critical
[INFO] Framework : express
[INFO] Running Express.js route scanner...
[✓] Found 7 routes in /tmp/auth-test
[INFO] GET /public/health → routes.js:6 [auth]
[INFO] GET /public/products → routes.js:7 [auth]
[INFO] GET /api/users → routes.js:9 [auth]
[INFO] POST /api/users → routes.js:13 [auth]
[INFO] GET /api/admin/dashboard → routes.js:17 [auth]
[INFO] GET /api/debug/reset → routes.js:21 [no auth]
[INFO] POST /api/test/seed → routes.js:22 [no auth]
[INFO] Detected spec: OpenAPI 3.x
[INFO] Spec contains 5 documented routes
[INFO] ──────────────────────────────────────────────────
[INFO] Total routes scanned : 7
[INFO] Documented : 5
[INFO] Undocumented : 2
[INFO] ──────────────────────────────────────────────────
╔══════════════════════════════════════════════╗
║ shadowaudit — Scan Report ║
╚══════════════════════════════════════════════╝
┌──────────┬────────┬───────────────────────────────────┬───────────────────────────────────┬──────┬──────┐
│ SEVERITY │ METHOD │ PATH │ FILE │ LINE │ AUTH │
├──────────┼────────┼───────────────────────────────────┼───────────────────────────────────┼──────┼──────┤
│ CRITICAL │ GET │ /api/debug/reset │ routes.js │ 21 │ NO │
├──────────┼────────┼───────────────────────────────────┼───────────────────────────────────┼──────┼──────┤
│ CRITICAL │ POST │ /api/test/seed │ routes.js │ 22 │ NO │
└──────────┴────────┴───────────────────────────────────┴───────────────────────────────────┴──────┴──────┘
┌─────────────────────────────────────────────┐
│ SCAN SUMMARY │
│ Total routes scanned : 7 │
│ Documented : 5 │
│ Undocumented : 2 │
│ ───────────────────────────────────────── │
│ 🔴 CRITICAL : 2 │
│ 🟡 HIGH : 0 │
│ 🔵 INFO : 0 │
└─────────────────────────────────────────────┘
⛔ Pipeline will FAIL — 2 critical shadow route(s) detected
Exit code: 1
In the terminal, severity cells are color-coded:

CRITICAL → red bold
HIGH → yellow bold
INFO → blue
METHOD → cyan
AUTH YES → green / NO → red
How It Works
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Express Scanner │ │ Spec Parser │ │ Delta Comparator│ │ Formatter │
│ (Babel AST) │ │ (OpenAPI/Swagger)│ │ (normalize + )│ │ (table/json/ )│
│ │ │ │ │ ( match routes )│ │ (sarif) )│
│ src//*.js │────▶│ openapi.json │────▶│ Route[] vs │────▶│ Findings[] │
│ src//*.ts │ │ swagger.yaml │ │ DocumentedRoute[]│ │ + stats │
│ │ │ │ │ │ │ │
│ + auth detector │ │ + basePath │ │ + severity │ │ + exit code │
│ (window scan) │ │ + serverPrefix │ │ scoring │ │ logic │
└──────────────────┘ └──────────────────┘ └──────────────────┘ └──────────────────┘
Express scanner uses @babel/parser + @babel/traverse to walk every .js/.ts file's AST and extract route definitions (app.get(), router.post(), router.route().get().post() chaining, etc.)
Auth detector scans a ±15-line window around each route for auth middleware patterns (inline or in surrounding scope), with sibling-route lines stripped to avoid false positives
Spec parser reads OpenAPI 3.x / Swagger 2.0 files (JSON or YAML), extracts documented routes, and normalizes path syntax ({id} → :id)
Delta comparator cross-references scanned routes against documented routes, reconciling Swagger basePath and OpenAPI servers[0].url prefixes, then scores each undocumented route as CRITICAL (no auth) or HIGH (has auth)
Formatter renders the report as a colored table, JSON, or SARIF 2.1.0
CI/CD Integration
GitHub Actions
name: Security Scan
on: [pull_request]

jobs:
shadowaudit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npx shadowaudit --dir ./src --spec ./openapi.json --format sarif > shadowaudit.sarif
continue-on-error: true
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: shadowaudit.sarif
- name: Fail on critical
run: npx shadowaudit --dir ./src --spec ./openapi.json --fail-on critical
Pre-commit hook

!/bin/bash

shadowaudit --dir ./src --spec ./openapi.json --fail-on critical
Project Structure
shadowaudit/
├── src/
│ ├── index.ts # CLI entry point
│ ├── config.ts # cosmiconfig loader (CLI flags + .shadowaudit.yml)
│ ├── comparator.ts # Delta comparator (route diffing + severity scoring)
│ ├── types.ts # Shared TypeScript interfaces
│ ├── scanners/
│ │ ├── express.ts # Express.js route extractor (Babel AST)
│ │ └── auth.ts # Auth middleware detector
│ ├── parsers/
│ │ └── spec.ts # OpenAPI 3.x / Swagger 2.0 parser
│ ├── formatters/
│ │ ├── table.ts # Colored terminal table
│ │ ├── json.ts # JSON output
│ │ ├── sarif.ts # SARIF 2.1.0 output
│ │ └── index.ts # Formatter dispatcher
│ └── utils/
│ └── logger.ts # Colored console output
├── tests/
│ ├── config.test.ts
│ ├── comparator.test.ts
│ ├── scanners/
│ │ ├── express.test.ts
│ │ └── auth.test.ts
│ ├── parsers/
│ │ └── spec.test.ts
│ └── formatters/
│ ├── table.test.ts
│ └── sarif.test.ts
├── .github/workflows/ci.yml
├── package.json
├── tsconfig.json
├── LICENSE
└── README.md
Development

Install dependencies

npm install

Build

npm run build

Run tests (45 tests across 8 test files)

npm test

Run in dev mode

npm run dev -- --dir ./src --spec ./openapi.json

Lint

npm run lint
Tech Stack
TypeScript — strict mode, ES2020 target, CommonJS modules
Babel (@babel/parser + @babel/traverse) — AST-based route extraction with error recovery
Commander.js — CLI argument parsing
chalk — terminal colors
cli-table3 — terminal table rendering
js-yaml — Swagger/OpenAPI YAML parsing
cosmiconfig — config file discovery
glob — recursive file scanning
Vitest — test runner
License
MIT © Ubaid ur Rehman 2026

Is Telegram Really Anonymous? Let’s Be Honest.

Dark Master — Tue, 28 Apr 2026 12:51:16 +0000

There’s this idea floating around — in tech circles, activist groups, even among regular people who just “heard it somewhere” — that Telegram is the anonymous, private messaging app. The one that governments can’t touch, hackers can’t crack, and cops can’t trace.

I want to gently push back on that. Not because Telegram is bad. It’s not. But because anonymous is a very specific word, and Telegram earns it only in very specific situations.

First, what does “anonymous” even mean?
There’s a difference between private and anonymous. Private means your content is hidden. Anonymous means your identity is unknown. You can have one without the other. Telegram promises a version of privacy. It mostly does not promise anonymity — and that matters.

The phone number problem
To use Telegram, you need a phone number. That’s it — that’s the conversation starter right there. Your phone number is your identity. It’s linked to a SIM card, which is linked to your name in most countries (especially in Pakistan, where NADRA ties every SIM to your CNIC).

Yes, you can hide your number from other users. But Telegram still knows it. And if someone subpoenas them, or a government agency sends a valid legal request to the country Telegram operates from at that moment — they have your number. And with your number, they have you.

The registration phone number is never truly hidden. It’s a persistent link between your real identity and your account — regardless of what name or photo you use.

What about “Secret Chats”?
Here’s where Telegram actually does something right. Secret Chats use end-to-end encryption (E2EE) via the MTProto 2.0 protocol. That means only you and the recipient can read those messages. Not Telegram, not their servers, not anyone intercepting traffic.

But here’s the catch most people miss: regular chats are NOT end-to-end encrypted. Your normal conversations — the ones in groups, channels, and standard DMs — are encrypted in transit and at rest, but Telegram holds the keys. That means they can technically read them. Or hand them over.

Secret chats

End-to-end encrypted
No cloud backup
Self-destruct timers
Device-to-device only
Regular chats

Cloud-stored by Telegram
Telegram holds the keys
Can be legally requested
No E2EE by default
Most people never touch Secret Chats. They use the default chat mode, sync across devices, and enjoy the convenience. That’s fine — but they shouldn’t call it anonymous.

The metadata issue
Even if your messages were perfectly encrypted, metadata is a whole other beast. Who you talk to, when, how often, from what IP address — this is metadata. Telegram collects some of it. And in intelligence and law enforcement, metadata is often more useful than content. It builds a map of your relationships, habits, and patterns.

Has Telegram actually handed over data?
Yes. After years of claiming they’d never comply, Telegram updated their privacy policy in late 2024 and acknowledged they can — and do — share user data with law enforcement under valid legal requests. This followed the arrest of Telegram’s CEO Pavel Durov in France in August 2024, which put significant pressure on the platform’s policies.

This isn’t a gotcha. It’s just reality. No company operating at Telegram’s scale can exist in a legal vacuum forever.

Real-world case

In 2024, following Durov’s arrest, Telegram disclosed that it had provided IP addresses and phone numbers of users to authorities in response to court orders — something they had previously implied would never happen.

So when IS Telegram relatively safe?
To be fair — and fairness matters here — Telegram is genuinely useful for certain threat models:

If you’re worried about a random hacker intercepting your traffic on public Wi-Fi, Telegram handles that fine. If you’re avoiding casual corporate surveillance or don’t want your messages sitting in a Google or Meta server, Telegram is better than WhatsApp for that. If you’re using Secret Chats for sensitive one-on-one conversations, the E2EE is solid.

Where it fails as an anonymity tool is against nation-state actors, legal subpoenas, or any adversary who can obtain your phone number and trace it back to you.

What should you use instead?
If actual anonymity is your goal — not just privacy, but real you-can’t-find-me anonymity — the honest answer involves tools like Signal (E2EE by default, minimal metadata, open source), Session (no phone number required, decentralized), or for the highest-risk situations, Briar or Cwtch over Tor.

Telegram is not in that category. It’s a feature-rich, fast, convenient messaging app with optional strong encryption. That’s a genuinely useful thing. Just don’t confuse convenience with anonymity.

Final verdict
Telegram is private-ish, not anonymous. It has good security features if you deliberately use them. It’s built by people who care about privacy more than, say, Meta does. But it’s not a shield against a determined, legally-equipped adversary.

The next time someone tells you “just use Telegram, they can’t track you” — you’ll know what to say.

Written from the perspective of someone who runs a Tor bridge, tests apps for F-Droid, and has spent way too many late nights reading privacy architecture docs. Take it with appropriate context.

I Built a File Encryption App in Rust. Here’s What I Learned About Trust.

Dark Master — Thu, 16 Apr 2026 10:17:55 +0000

I’m 17. I live in Karachi. I have 8GB of RAM and a laptop that throttles if you look at it wrong.

And I just shipped a desktop encryption app in Rust.

Not because someone asked me to. Because I needed it to exist.

Why Rust

I could’ve done this in Python in a weekend. But Python wouldn’t give me what I actually wanted — control. When you’re encrypting someone’s files, you don’t want a garbage collector making decisions behind your back. You don’t want mystery allocations. You want to know exactly what’s in memory and when it leaves.

Rust forces that conversation. The borrow checker is annoying until it saves you from a mistake you didn’t know you were making.

It took longer. It was worth it.

The Stack

AES-256-GCM-SIV for encryption. Argon2id for key derivation. HKDF-SHA512 to stretch the key material. egui for the UI because I didn’t want to ship an Electron app that weighs 200MB to encrypt a text file.

Each of these choices was deliberate. GCM-SIV over plain GCM because nonce reuse is a real-world failure mode, not a theoretical one. Argon2id because it’s memory-hard and scrypt has a worse story on GPUs. HKDF because you should never use a password directly as a key.

Security isn’t one big decision. It’s a hundred small ones.

18 Bugs

The first version had 18 bugs. I’m not hiding that. UTF-8 panics on non-ASCII filenames. The NSIS installer writing to the wrong path. A title bar gap being counted twice in the layout.

Become a Medium member
Most of them were embarrassing in hindsight. None of them were unfixable.

I used AI tooling heavily — Roo Code, Jules — to move through them faster. The AI didn’t replace the thinking. It replaced the typing. I still had to understand every change before it merged.

That distinction matters.

Why This Project, Really

Here’s the honest answer.

I live in a part of the world where privacy is not a default. Where your data going somewhere you didn’t intend is normal. Where you can’t always trust the platform, the app store, or the company behind the software you’re using.

I’m also Muslim. There’s a word in Arabic — amanah — it means a trust. Something given to you that you are responsible for. I think about that a lot when I think about other people’s files, other people’s messages, other people’s data.

If you handle someone’s information, that’s an amanah. Most software treats it like a liability.

I wanted to build something that treats it like what it actually is.

What’s Next

The app is called Neuron-Encrypt. It’s on GitHub. It’s GPL-v3 because I don’t want it locked behind anyone’s business model.

Version 1 works. It encrypts. It installs. It doesn’t phone home.

Version 2 will do more. But I’d rather ship something honest and small than something bloated and impressive-looking.

If you’re a developer who cares about this stuff — not the buzzwords, the actual problem — I’d like to hear from you.

Ubaid ur Rehman is a DAE Electronics student in Karachi building FOSS privacy tools. GitHub: darkmaster0345.