This page describes the classes of attack the DigiFX Media Console is built to resist, and the standard by which we decide a boundary is actually defended rather than merely assumed safe.
01How a boundary gets charted
Every place untrusted data crosses into the system is charted the same way: the boundary, the attack vector against it, the defense, and the permanent test that pins that defense in place. A boundary with a defense but no test that fails when the defense is removed is recorded as unguarded, not as protected. New surfaces inherit the same requirement rather than starting from zero.
That rule exists because of a specific failure pattern we found in our own code: validators that were correct, sitting in the same file as the functions that never called them. Writing the check is not the work. Proving the door uses its lock is.
02The classes that actually apply here
- Credential attacks. Brute force against a known address, credential stuffing from breach corpora, and account enumeration — probing whether a given email has an account at all.
- Payment-rail abuse. Replayed webhook deliveries that could grant the same credits twice, tampered or malformed amounts, and payment-identity substitution — pointing one account's billing record at another account's payment identity.
- Forged client writes. A browser writing a record that makes it look like it paid, or reaching data belonging to another account by tampering with the client.
- Hostile input on public forms. Script payloads in free-text fields, oversized values, patterns crafted to make matching run long, and link stuffing.
- Identifier manipulation. Specially crafted lookup keys designed to reach an inherited object property instead of a real catalog entry.
- Growth as denial of service. Append-only records that eventually reach a hard per-document size limit and begin rejecting new writes. This class is easy to miss because it lands on the busiest accounts first.
03Where the authoritative defense lives
Console authentication runs on Google's Firebase Identity Platform. There is no DigiFX-owned login endpoint to attach rate-limiting middleware to, so the authoritative rate limit, bot scoring, and enumeration resistance are provider configuration rather than application code.
The Console does ship its own sign-in throttle and its own password gate, and we describe both honestly: they slow casual abuse through the interface, and a client-side control cannot bind anyone talking to the authentication API directly. Data access is the opposite case — read and write authority is enforced on the server by database rules, so a tampered client changes nothing about what it is allowed to see.
04What we do not claim
DigiFX holds no security certification. We have not completed a SOC 2 audit, an ISO 27001 certification, or any comparable third-party assessment. No system is perfectly secure, and you should keep your own backups of work that matters to you.