# PharosHub

> Web application security for sites that are already built. The flagship
> capability, Hallmark, cryptographically seals a published site so a page
> altered after it left the build cannot pass as genuine.

## What the product is

PharosHub is a SaaS security product installed as an npm package
(@pharoshub/guard) inside a customer's existing application. There is no agent
to run, no server to provision and no DNS to repoint.

## Hallmark — the primary capability

Problem it addresses: every common web security control assumes the attacker is
outside. Once a hosting account, build server or CDN is compromised, a firewall
sees legitimate requests, a bot filter sees a normal visitor, and the security
headers are being served by the attacker. The realistic attack at that point is
not defacement but a single altered line — a support phone number replaced, a
payment form inserted, an account number changed by two digits. The page loads
correctly and nothing in a standard stack is looking for it.

How it works:
  1. At build time the customer's site is fingerprinted (SHA-256 per file).
     Only the list of hashes is sent to PharosHub. The files never leave the
     customer's infrastructure.
  2. PharosHub signs that list with ECDSA P-256. The private key is held only
     by PharosHub and is never placed on the customer's servers, build system,
     CDN, or in our database.
  3. The signature ships inside the customer's own deploy and is served from
     their own CDN. PharosHub is not in the path of any page view.
  4. In the visitor's browser, the delivered page is hashed and compared
     against the signed manifest, using a public key that can only verify.

Security property: an attacker with full control of the customer's hosting,
build pipeline and CDN can change anything, but cannot produce a signature that
verifies.

## What Hallmark does NOT do

  - It does not block. It reports. A page is never prevented from loading for a
    visitor. Blocking is withheld deliberately: the dangerous failure mode is
    wrongly telling a visitor a genuine page is compromised.
  - It does not remove or take down anything.
  - It does not protect against attacks that do not alter published files —
    for example abuse of a working login form.
  - The browser-side verifier is served by the same origin it checks, so an
    attacker with complete control of that origin can remove it. It catches
    compromises that alter content without auditing every script.
  - Mismatches are frequently innocent: corporate proxies that rewrite HTML,
    antivirus software, ISP injection, or a deploy landing while a visitor had
    an older page open. Findings are therefore weighted by how many independent
    visitors report the same file.

## How it fails

Every failure path is open, by design. Missing keys, no network, PharosHub
unavailable, or a lapsed subscription all result in the customer's build
completing with a warning and the site serving normally. The protection is
absent; nothing is broken.

## Commercial enforcement

A seal carries an expiry inside the signature, derived from the subscription
plus a grace period. It cannot be extended by editing the deployed file, as
that invalidates the signature. A lapsed subscription therefore stops being
protected rather than continuing indefinitely.

## The active honeypot — the second flagship

Most honeypots watch. This one acts, without ever touching the attacker's
machine.

Trap paths (/.env, /wp-login.php, /.git/config and similar) exist only to be
requested by something that should not. A single hit is answered with a plain
refusal and recorded. But a source that keeps working the surface — four
distinct trap paths, or an exploit-shaped request corroborated by other
probing — is escalated: the refusal is replaced by a convincing but entirely
fake admin login. The attacker's attempt is captured, and the page hands them a
honeytoken: a credential that looks live, is never valid, and whose use anywhere
is unauthorised by construction. When they carry it back and use it, that is
proof of who they are — obtained because they came to us, not because anything
reached out to them.

False positives are prevented structurally, not by tuning. The decoy occupies
only trap paths, which no legitimate request reaches — a mistyped real URL
(/properties for /property) is not a trap and gets an ordinary 404. Even a
source already flagged still receives the real site on every real route,
because the decoy never occupies one. The worst a false positive can do is show
a scanner a fake login instead of a refusal; a real visitor cannot see it.

## What the active honeypot does NOT do

  - It does not hack back, retaliate, or run any code on the attacker's machine.
    It records only what the attacker sends to us — their inputs, address and
    tooling. This is observation of our own inbound traffic, and the boundary is
    enforced by there being no code path that reaches outward.
  - It does not store what an attacker types into the decoy. A submitted
    password is recorded as "an attempt was made", never as a value.
  - It does not engage on a single stray request, and does not engage a
    reverse-DNS-verified crawler at all.
  - The decoy is a self-contained dead end with no route to any real data; it is
    not a real system left deliberately vulnerable.

## Plans

  Watch
    Traps on your site, and someone to tell you when one is sprung.
    - deception
    - attacker_intel

  Guard
    Your published pages, sealed — and everything around them watched.
    - deception
    - attacker_intel
    - page_integrity
    - clone_detection
    - script_integrity
    - lookalike_domains
    - edge_audit
    - credential_abuse
    - exposure_scan

  Managed
    Sealed pages and full deception, plus edge protection we hold for you.
    - deception
    - clone_detection
    - attacker_intel
    - page_integrity
    - script_integrity
    - lookalike_domains
    - edge_audit
    - credential_abuse
    - exposure_scan
    - managed_edge

## What we do not claim

  - No security certification, audit or compliance attestation is claimed.
  - No detection rate, uptime figure or performance benchmark is claimed.
  - Hallmark is a detection and verification control, not a preventive one.
  - The technique combines established primitives (content hashing, asymmetric
    signatures, browser-side verification). The product is the packaging and
    the key custody model, not a novel cryptographic invention.

## Data handling

Sent to PharosHub: file paths and their hashes; honeypot hit metadata (source
IP, path, user agent, timestamp); decoy interactions (the username an attacker
tried, and the fact a password was submitted — never its value); honeytoken use;
unauthorised-host reports. Never sent: page content, files, visitor personal
data, legitimate form contents, cookies or credentials.

## Links

  - Documentation: https://www.pharoshub.cloud/docs
  - How it works: https://www.pharoshub.cloud/how-it-works
  - Security posture: https://www.pharoshub.cloud/security
  - Pricing: https://www.pharoshub.cloud/pricing
  - Contact: https://www.pharoshub.cloud/contact
  - Public verification key: https://www.pharoshub.cloud/i/key