ColdFusion Security
ColdFusion security built into the architecture
Security isn't a layer you add at the end — it's the rules the whole system follows. Validation at every boundary, encoding on every exit, authorization on every action, and errors that fail safe. Here's how we build it in.
Most breaches aren't exotic. They're the boring ones, skipped.
The compromises we've seen in ColdFusion applications are rarely the dramatic, zero-day kind. They're the mundane ones: an input field that trusted its client-side validation, an output that wasn't encoded, a query that concatenated a value, a session that was never hardened, an error page that showed the server its guts. Each one is small. Each one is preventable. And each one is exactly the kind of thing that's invisible until it isn't.
That's why security in our work is structural. It's not a pen test you run before launch or a plugin you install. It's a set of rules the entire system follows — validate at the edge, encode at the exit, authorize the action, fail safe and log loud — applied the same way on every build, by default, without someone having to remember.
This page is a working description of that model: the specific controls, where they live in the architecture, and what they look like in real code. It's also an honest one — about what security can and can't promise.
The Controls
The specific controls, and where they live
Input validation
Every external value — form, URL, header, file — checked against an explicit rule: type, length, pattern, range. The client side gives feedback; the server side is the gate.
Output encoding
Whatever we store or display is encoded for its context — HTML, attribute, script, URL. This is what turns a stored value from a vector into a non-event.
Secure queries
Every value bound with cfqueryparam or the ORM. No concatenation, no exception. This closes SQL injection and, as a bonus, makes queries cacheable and fast.
Sessions & auth
Secure session flags, appropriate lifetimes, HttpOnly, and logout that actually logs out. Authentication designed, not assumed.
Authorization
Every privileged operation checks the role — the action, not just the page. Row-level scoping so one user never sees another's data.
Safe error handling
Errors are caught centrally. Users see a calm, generic message; the log gets the full picture. Stack traces and server paths never reach the browser.
Defense in Depth
Why one control is never enough
A single control failing should never be the thing that breaks the system. That's the whole point of defense in depth: if validation has a gap, encoding is still there. If encoding is bypassed somewhere, the query was still bound. If the application logic has a flaw, the authorization check at the action level still stands.
Each layer assumes the one before it might not be perfect — and it isn't, because it's written by humans. The layers don't make any one of them unnecessary; they make the system resilient to the fact that none of them is perfect.
That's also why security can't be a final gate. It has to be present in every layer, from the first input to the last output, because the failure mode you're defending against is precisely a gap somewhere in that chain.
The chain, end to end
- Untrusted input enters at a named boundary
- It's validated against an explicit rule
- It's used through a bound query or safe API
- The result is encoded for its output context
- Every privileged step re-checks authorization
- Any failure is logged in full, shown minimally
The Honest Part
What security can and can't promise
Anyone who tells you an application can be made "secure" — full stop, guaranteed, forever — is selling you something. New vulnerabilities are found. New attack patterns appear. Dependencies change. Security is a posture you maintain, not a state you achieve and then forget.
What we can do, and do consistently, is this: apply a defense-in-depth model that closes the known classes of weakness; keep the system current so the holes being exploited right now aren't open in your code; instrument it so new anomalies surface in a log instead of a breach; and hand you the documentation and monitoring to keep it that way.
That's the honest version of "we secure your application." It's less impressive in a sales pitch and substantially more real in an incident. We'd rather have the second kind.
What you get from a review
- Findings ranked by real-world risk, not severity theater
- Specific remediation for each significant finding
- A picture of your session, query, and error posture
- A monitoring setup that catches the new, not just the old
- A written report you can act on with any team
Related
Security in context
Security is one part of a healthy system. These are the others it works with.