Forty-nine classes of weakness we track and defend against, and the layers that close them. Not an audit we run at the end — the way we write code from the first commit.
Every line below is a real failure we've seen in products we inherited. None of them are hypothetical.
Security isn't a phase you add at the end. It's a property of how you write code — or it isn't a property at all. A pentest on the day before launch tells you what's broken. It doesn't give you time to fix it.
No single control has to be perfect. That's the point of defense in depth — if one layer fails, the next one catches it.
The outer wall. Controls that sit between your software and the traffic trying to reach it.
The vault. Even if someone gets through, the data they find is useless without the keys.
The patterns we apply on every project, on every stack. None of them are exotic — most attacks are stopped by the boring disciplines, not the clever ones.
Every database call uses prepared statements. No string concatenation, no exceptions, no "just this once."
Data is encoded for the context it lands in — HTML, attribute, JavaScript, URL. Different rules for each.
Validate on entry, encode on output. Both sides of the boundary, every field, every time.
A strict CSP blocks inline scripts and limits resource origins. XSS defense at the browser level.
Session cookies can't be read by JavaScript, travel only over TLS, and stay on the originating site — killing most CSRF.
Every route and API endpoint checks authorization, not just authentication. The framework never assumes it.
Uploads accept only approved types and storage sits outside the web root. The file can never execute.
Secrets live in environment variables or a vault. Never in code, never in repos, never in client-side bundles.
Every build checks dependencies against the CVE database. A critical CVE blocks the pipeline until fixed.
Auth and API endpoints cap requests per IP and per user. Brute force and scraping stop being free.
HSTS, X-Frame-Options, X-Content-Type-Options set by default. The browser becomes part of the defense.
Logs capture what happened — request IDs, user IDs, event types. Never credentials, never PII.
Grouped by what they attack, rated by severity and exploit complexity. We track them by CWE identifiers — the same catalog OWASP draws from.
| CWE | Weakness | What it does | Severity | Exploit complexity |
|---|---|---|---|---|
| Injection & code execution | ||||
| CWECWE-79 | WeaknessCross-site scriptingXSS, HTML injection | What it doesInjecting scripts into pages to steal or manipulate data. | SeverityCritical | Exploit complexityModerate |
| CWECWE-787 | WeaknessOut-of-bounds writeMemory corruption | What it doesWriting data to memory locations it doesn't own. | SeverityCritical | Exploit complexityDifficult |
| CWECWE-89 | WeaknessSQL injectionSQLi | What it doesManipulating database queries to access or destroy data. | SeverityCritical | Exploit complexityModerate |
| CWECWE-352 | WeaknessCSRFSession riding | What it doesTricking authenticated users into actions they didn't intend. | SeverityCritical | Exploit complexityModerate |
| CWECWE-78 | WeaknessOS command injectionShell injection | What it doesRunning unauthorized system commands through the app. | SeverityCritical | Exploit complexityModerate |
| CWECWE-94 | WeaknessCode injectionImproper code generation | What it doesInjecting code to change application behavior. | SeverityCritical | Exploit complexityModerate |
| CWECWE-77 | WeaknessCommand injectionSpecial element injection | What it doesInjecting commands to control the host system. | SeverityCritical | Exploit complexityModerate |
| CWECWE-918 | WeaknessSSRFServer-side request forgery | What it doesTricking the server into making requests to internal resources. | SeverityCritical | Exploit complexityDifficult |
| CWECWE-611 | WeaknessXML external entityXXE | What it doesProcessing XML with external entity references that read files or hit internal services. | SeverityHigh | Exploit complexityModerate |
| CWECWE-90 | WeaknessLDAP injectionLDAPi | What it doesManipulating LDAP queries through unchecked user input. | SeverityHigh | Exploit complexityModerate |
| CWECWE-643 | WeaknessXPath injectionXPathi | What it doesInjecting XPath to manipulate XML data access. | SeverityMedium | Exploit complexityModerate |
| CWECWE-1336 | WeaknessServer-side template injectionSSTI | What it doesInjecting template directives that run server-side code. | SeverityCritical | Exploit complexityModerate |
| Access control | ||||
| CWECWE-862 | WeaknessMissing authorizationAuthZ | What it doesLetting users reach resources they shouldn't. | SeverityCritical | Exploit complexityModerate |
| CWECWE-287 | WeaknessImproper authenticationAuthN | What it doesWeak or missing identity checks at the login door. | SeverityCritical | Exploit complexityModerate |
| CWECWE-269 | WeaknessImproper privilege management— | What it doesGiving users more power than their role requires. | SeverityCritical | Exploit complexityModerate |
| CWECWE-863 | WeaknessIncorrect authorizationAuthZ | What it doesAllowing access without the right checks in place. | SeverityCritical | Exploit complexitySimple |
| CWECWE-639 | WeaknessInsecure direct object referenceIDOR | What it doesLetting users reach other users' data by changing an ID in the URL. | SeverityCritical | Exploit complexitySimple |
| CWECWE-732 | WeaknessPrivilege escalationVertical / horizontal | What it doesGaining higher privileges than the role grants. | SeverityCritical | Exploit complexityModerate |
| CWECWE-306 | WeaknessMissing auth for critical function— | What it doesNo identity check on an action that demands one. | SeverityCritical | Exploit complexitySimple |
| CWECWE-384 | WeaknessSession fixation— | What it doesForcing a user's session ID to impersonate them. | SeverityHigh | Exploit complexityModerate |
| Input & file handling | ||||
| CWECWE-22 | WeaknessPath traversalDirectory traversal | What it doesAccessing files outside the allowed directories. | SeverityCritical | Exploit complexityModerate |
| CWECWE-434 | WeaknessUnrestricted file uploadDangerous file type | What it doesAccepting files that carry malware or executable code. | SeverityCritical | Exploit complexityModerate |
| CWECWE-20 | WeaknessImproper input validation— | What it doesNot checking incoming data for harmful content. | SeverityCritical | Exploit complexitySimple |
| CWECWE-502 | WeaknessDeserialization of untrusted dataUnmarshaling, unpickling | What it doesProcessing untrusted serialized data, leading to remote code execution. | SeverityCritical | Exploit complexityDifficult |
| CWECWE-601 | WeaknessOpen redirectUnvalidated redirect | What it doesRedirecting users to attacker-controlled URLs via a parameter. | SeverityMedium | Exploit complexitySimple |
| Memory safety | ||||
| CWECWE-125 | WeaknessOut-of-bounds readOOB read | What it doesReading memory that should be off-limits. | SeverityCritical | Exploit complexityModerate |
| CWECWE-416 | WeaknessUse after freeDangling pointer | What it doesAccessing memory after it's been released. | SeverityCritical | Exploit complexityDifficult |
| CWECWE-120 | WeaknessBuffer overflow— | What it doesWriting past the end of a buffer, overwriting adjacent memory. | SeverityCritical | Exploit complexityDifficult |
| CWECWE-190 | WeaknessInteger overflow / underflow— | What it doesArithmetic results exceeding the type's range, leading to logic errors. | SeverityHigh | Exploit complexityModerate |
| Data exposure & leakage | ||||
| CWECWE-200 | WeaknessInformation disclosureInformation leak | What it doesExposing sensitive data to users who shouldn't see it. | SeverityCritical | Exploit complexitySimple |
| CWECWE-312 | WeaknessSensitive data exposurePlaintext storage | What it doesStoring passwords, tokens, or PII without encryption or hashing. | SeverityCritical | Exploit complexitySimple |
| CWECWE-524 | WeaknessCache exposes sensitive data— | What it doesCached responses containing credentials or personal data. | SeverityHigh | Exploit complexitySimple |
| CWECWE-598 | WeaknessInformation in query stringsURL leak | What it doesSensitive data captured in URLs, logged by proxies and browsers. | SeverityMedium | Exploit complexitySimple |
| CWECWE-209 | WeaknessError message information leakStack trace leak | What it doesErrors that reveal internals — stack traces, framework versions, paths. | SeverityMedium | Exploit complexitySimple |
| CWECWE-201 | WeaknessCross-site leakXS-Leak | What it doesSide-channel attacks that read cross-origin state through browser APIs. | SeverityMedium | Exploit complexityDifficult |
| Cryptography | ||||
| CWECWE-798 | WeaknessHard-coded credentials— | What it doesPasswords, keys, or tokens baked into source code. | SeverityCritical | Exploit complexitySimple |
| CWECWE-330 | WeaknessInsufficient entropyWeak randomness | What it doesRandom values predictable enough to guess — session IDs, tokens, salts. | SeverityHigh | Exploit complexityModerate |
| CWECWE-327 | WeaknessInsecure cryptographic hashMD5, SHA1 | What it doesUsing deprecated hashes for passwords or integrity checks. | SeverityHigh | Exploit complexitySimple |
| CWECWE-311 | WeaknessMissing encryption of sensitive data— | What it doesData stored or transmitted in plaintext where encryption is required. | SeverityCritical | Exploit complexitySimple |
| CWECWE-338 | WeaknessInsecure randomnessPRNG misuse | What it doesUsing non-cryptographic RNGs for security-sensitive values. | SeverityHigh | Exploit complexityModerate |
| Configuration & deployment | ||||
| CWECWE-16 | WeaknessSecurity misconfiguration— | What it doesDefault, verbose, or permissive configurations left in production. | SeverityHigh | Exploit complexitySimple |
| CWECWE-1188 | WeaknessInsecure default configurations— | What it doesShipping with defaults that assume trust — admin routes open, debug enabled. | SeverityHigh | Exploit complexitySimple |
| CWECWE-1104 | WeaknessVulnerable & outdated componentsKnown CVEs | What it doesDependencies with known vulnerabilities, left unpatched. | SeverityHigh | Exploit complexitySimple |
| CWECWE-295 | WeaknessImproper certificate validationTLS bypass | What it doesSkipping or weakening cert checks, opening the door to MITM. | SeverityHigh | Exploit complexitySimple |
| CWECWE-668 | WeaknessAdmin & debug interfaces exposed— | What it doesAdmin panels, debug endpoints, or metrics routes reachable from the public internet. | SeverityHigh | Exploit complexitySimple |
| Session & API | ||||
| CWECWE-285 | WeaknessBroken function level authorizationBFLA | What it doesAPI endpoints that perform privileged actions without authorization checks. | SeverityCritical | Exploit complexitySimple |
| CWECWE-213 | WeaknessExcessive data exposure via API— | What it doesAPI responses returning more data than the client needs, including sensitive fields. | SeverityHigh | Exploit complexitySimple |
| CWECWE-770 | WeaknessLack of rate limitingNo throttling | What it doesUnbounded requests enable brute force, scraping, and enumeration. | SeverityMedium | Exploit complexitySimple |
| CWECWE-915 | WeaknessMass assignmentAuto-binding | What it doesBinders accepting fields the user shouldn't control — role, isAdmin, etc. | SeverityHigh | Exploit complexitySimple |
The memory safety classes — buffer overflow, out-of-bounds read/write, use-after-free, integer overflow — apply to native dependencies and tooling, not your application code. We track them because every stack runs on C libraries somewhere, and a CVE in libwebp or OpenSSL hits production the same as a SQL injection.
Each layer covers different categories. Some need two layers. Session & API spans all three — that's where defense in depth earns its name.
Five of the eight categories are defended at two or more layers. Session & API touches all three — which is why it sits on its own row, not folded into one. When a weakness crosses boundaries, the controls do too.
A checklist we close on every project before launch. Nothing leaves staging with an open box.
“The product is stable and delivering positive outcomes for customers. They deliver on time, are responsive, and provide helpful feedback and push back when necessary. They stayed involved as the product evolved.”
Security isn't a separate track. It lives inside the same six-phase process we run on every project — just with teeth at each step.
Threat modeling, security requirements, compliance scope
Secure architecture, auth model, data flow mapping
Input validation, parameterized queries, secret management
Pentest, dependency scanning, automated security gates
Environment hardening, security checklist, monitoring
Patching, incident response, periodic audits
Our internal list lines up with the OWASP Top 10 (2021). Every category is covered by at least one of the weakness classes we track — or by a process step.
Addressed through threat modeling and security requirements in the Plan phase.
Addressed through structured logging, alerting, and incident response in the Maintain phase.
A04 (Insecure Design) and A09 (Logging & Monitoring) aren't single weaknesses — they're properties of the process. We address them through threat modeling in the Plan phase and structured logging in the Maintain phase.
Yes. We pentest before launch and on a regular cadence after. We also run automated security scans in CI, so most issues get caught long before a human picks up a tool.
We track the OWASP Top 10 and the broader CWE catalog. The forty-nine classes on this page are our baseline — every project checks against them before launch, and the OWASP mapping section shows how they line up.
All of them. The names change — parameterized queries look different in Node and Python — but the patterns don't. We apply the same list to React, Next.js, NestJS, FastAPI, and anything else we build with.
AES-256-GCM for data at rest. TLS for data in transit. Encryption keys are managed separately from the data they protect, rotated on a schedule, and never hardcoded.
We design for the regulations that apply to your product. We've shipped HIPAA-adjacent healthcare platforms and GDPR-compliant products for EU clients. We don't hand you a compliance certificate — we build the controls that make one possible.
Yes. Monitoring, alerting, and a patching cadence are part of maintenance. When a new CVE drops for a dependency we use, you hear about it from us, not from the news.
Environment variables and secret managers. Never in repos, never in client-side code. We audit for accidental exposure and rotate keys when team members change.
Tell us what you're building and what's at stake. We'll walk you through the controls that apply — and where they fit in the process.