Cybersecurity

Findings you can reproduce. Fixes you can merge.

We test web apps, APIs, build pipelines, infrastructure, and multiplayer game servers the way an attacker would, within a scope you authorize in writing. Every finding comes with a severity, reproduction steps, and a specific fix. We build software too, so we can write the patch and retest it.

What we cover

The areas overlap. Reviewing a web app usually means reviewing the headers it ships with and the pipeline that builds it, too.

  1. Application security review

    Source review and hands-on testing of the code paths attackers try first.

    • Sign-in, sessions, and account recovery
    • Access control: IDOR, privilege escalation, tenant isolation
    • Injection, SSRF, path traversal, and file uploads
    • Payment flows and webhook signature checks
    • API validation, rate limits, and error leakage
  2. Web platform hardening

    Browser-enforced controls that contain a bug once one gets through.

    • Content-Security-Policy with hashes or nonces, no 'unsafe-inline'
    • Trusted Types for DOM injection sinks
    • HSTS, COOP, CORP, and Permissions-Policy
    • Cookie flags, passkeys (WebAuthn), and session lifetime
    • CDN features that rewrite or cache your responses
  3. Supply chain and CI

    What gets into your build, and who can change it.

    • Dependency and lockfile review
    • Advisory triage: is the vulnerable code reachable from yours?
    • Release-age, provenance, and install-script policies
    • GitHub Actions pinned to commit SHAs, with least-privilege tokens
    • CI secrets, and SBOMs for what you ship
  4. Infrastructure and access

    Hosts, containers, and cloud accounts set up so one mistake stays small.

    • Non-root, read-only containers with minimal capabilities
    • Linux host hardening and patch levels
    • Exposure review: open ports, admin panels, forgotten hosts
    • No inbound ports where a tunnel or private network will do
    • AWS IAM least privilege, secrets storage, and rotation
  5. Game security

    In a multiplayer game the client is hostile. We check that your server treats it that way.

    • Server-authoritative design: what the client decides, and what it only requests
    • Validation of every remote call and replicated value
    • Economy exploits: item duplication, race conditions, replayed purchases
    • Rate limits on player actions, and player data integrity
    • Game backends, admin tools, and the website around the game

    Engine-agnostic: the review follows your server and network code.

  6. Security for what we host

    When we host what we build, keeping it secure is part of the job.

    • OS, container, and dependency updates
    • Images pinned by digest, and atomic deploys with rollback
    • Monitoring, logs, and backups with tested restores
    • A written runbook for each system: contacts, rollback, and restore steps

Languages

  • TypeScript
  • JavaScript
  • Go
  • Rust
  • Python

Platforms

  • Node.js
  • Next.js
  • React
  • PostgreSQL
  • Linux
  • Docker
  • Cloudflare
  • AWS

Tell us what to test.

Send a few lines about the system and what worries you. We'll reply with questions and a proposed scope.

To report a vulnerability in our own systems, email security@plentex.app.