SimplifiedCS

Authorization checks are missing or incorrectly enforced, letting authenticated users act outside their intended permissions - e.g., accessing another user's records by changing an ID in a URL.

1. Enforce authorization server-side on every request - never trust client-side role checks alone; a hidden button or greyed-out UI element is not an access control, since the underlying API endpoint is still directly reachable.
2. Deny by default and grant access explicitly per resource and role, and specifically test for Insecure Direct Object Reference (IDOR) by attempting to access another user's resource by changing an ID/UUID in the request - this is the single most common real-world instance of this category.
3. Verify object-level authorization for any endpoint accepting a user-supplied ID (order ID, invoice ID, file path) - confirm the requesting user actually owns or has rights to that specific object, not just that they're authenticated at all.
4. Centralize access-control logic in a single reusable middleware/policy layer (a policy-as-code approach like OPA or Casbin, or your framework's built-in authorization middleware) rather than duplicating ad hoc checks per endpoint, where one omitted check becomes the exploitable gap.
5. Disable directory listing and restrict CORS configuration to explicit, known origins rather than a wildcard (*) - both are common, easily-checked broken-access-control misconfigurations distinct from application logic flaws.
6. Log and alert on repeated authorization failures from a single account or source IP (e.g. more than a handful of 403 responses within a short window) - this pattern typically indicates automated ID enumeration/IDOR probing in progress.

Sensitive data is transmitted or stored without adequate encryption, or with weak/outdated algorithms, exposing it if intercepted or if storage is breached.

1. Encrypt sensitive data at rest using current, vetted algorithms - AES-256 is the standard baseline; for databases, use built-in transparent data encryption (SQL Server TDE, RDS encryption-at-rest) rather than relying on disk-level encryption alone.
2. Encrypt data in transit with TLS 1.2 minimum, TLS 1.3 where supported, for every connection carrying sensitive data - including internal service-to-service traffic, not just the public-facing edge, since lateral movement inside a flat network can otherwise intercept unencrypted internal calls.
3. Never store passwords in plaintext or reversible encryption - use a purpose-built password hashing function (bcrypt, scrypt, or Argon2id) with an appropriately-tuned work factor, never a general-purpose hash like MD5/SHA-1/SHA-256 alone, which are fast by design and trivially brute-forced for password use.
4. Disable legacy TLS versions (SSLv3, TLS 1.0/1.1) and weak cipher suites in the server/load-balancer configuration - verify with Qualys SSL Labs' free SSL Server Test that the actual negotiated configuration matches intent, since a config change doesn't always take effect the way it's expected to.
5. Classify data by sensitivity (public/internal/confidential/restricted) so encryption requirements match actual risk rather than one blanket policy - this also determines what needs field-level encryption (SSNs, card data) versus what's adequately covered by disk/transport encryption alone.
6. Manage encryption keys through a dedicated key management service (AWS KMS, Azure Key Vault, HashiCorp Vault) with defined rotation, rather than embedding keys in application config or source - a strong algorithm with a poorly-managed key provides little real protection.

Untrusted input is interpreted as executable code or commands by an interpreter (SQL, OS shell, LDAP), letting an attacker manipulate queries or execute arbitrary commands.

1. Use parameterized queries/prepared statements everywhere user input reaches a database call - your framework or ORM's parameter-binding API (?/:param placeholders), never string/template concatenation, including for dynamically-built search or filter queries, which is where developers most often fall back to concatenation.
2. Validate and sanitize all input server-side using allow-lists (accept known-good patterns) rather than deny-lists (block known-bad patterns) - deny-lists are reliably bypassed by encoding tricks; an allow-list for a numeric ID parameter that only accepts digits closes the injection path regardless of payload.
3. Apply least-privilege database accounts so a successful injection has limited reach: the application's DB account should never be the database's admin/root account, and shouldn't have DROP, ALTER, or cross-schema access it doesn't functionally need.
4. Deploy a WAF with injection-pattern rules (the OWASP ModSecurity Core Rule Set, or the managed rule sets built into Cloudflare/AWS WAF/Azure Front Door) as a compensating layer in front of the application - this catches many real-world attempts while underlying code is still being remediated.
5. Run static analysis (SAST) for injection patterns in CI/CD - Semgrep's public ruleset, Bandit for Python, or GitHub CodeQL's default query set - configured to flag on pull request, not just generate a report no one reads.
6. Enable database query logging or a database activity monitoring tool during and after remediation to catch anomalous query patterns (unexpected UNION clauses, unusually long query strings from application service accounts) against endpoints not yet fully patched.

The application's underlying architecture or business logic contains exploitable flaws that no amount of secure coding can fix, because the design itself doesn't account for abuse cases.

1. Threat-model new features before writing code, not after - a lightweight structured method like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) applied to a feature's data flow is enough to catch most design-level gaps without needing a dedicated security engineer to run it.
2. Build abuse-case testing into design review specifically, not just functional testing: for every "happy path" user story, write at least one corresponding abuse case ("what happens if this user skips a step / submits a negative quantity / replays this request") and confirm the design accounts for it.
3. Apply rate limiting and business-logic limits at the design stage for anything with real-world consequences (checkout flows, password reset, referral/promo codes) - failures here (unlimited promo-code redemption, no cap on reset attempts) are business-logic flaws that secure coding alone can't fix after the fact.
4. Use secure design patterns and reference architectures rather than one-off solutions - for common needs like authentication, session management, or file upload, prefer a vetted library/framework feature over custom-built logic, since custom implementations of these specific patterns have a long track record of reintroducing known flaws.
5. Segregate tiers by trust level at the architecture stage (a DMZ for anything internet-facing, isolated from internal systems that don't need direct exposure) - a design decision that's expensive to retrofit but straightforward to get right upfront.
6. Maintain a running record of previously identified design flaws so they aren't repeated in the next feature or application - insecure-design issues tend to recur across a codebase once introduced, since the same team often repeats the same pattern elsewhere.

Default accounts, unnecessary features, verbose error messages, or open cloud storage are left enabled, giving attackers an easy, often automated, path in.

1. Harden configurations using a repeatable, automated baseline (Infrastructure as Code - Terraform, CloudFormation, or Ansible) rather than manual one-off server setup, so every environment starts from the same known-secure configuration and drift is easier to detect against a defined source of truth.
2. Apply a recognized hardening benchmark (the CIS Benchmarks for your specific OS/platform, freely available from the Center for Internet Security) rather than an ad hoc internal checklist, and automate the check with a tool like OpenSCAP or your cloud provider's native compliance scanner.
3. Disable or remove unused features, ports, services, and default accounts on every system before production - including admin consoles, sample applications, and default credentials that ship enabled on many platforms and appliances out of the box.
4. Regularly scan for configuration drift, not just once at deployment - a scheduled compliance scan (weekly or on every change) catches manual out-of-band changes that bypass your IaC pipeline, which is how most real-world drift actually happens.
5. Ensure error handling doesn't leak stack traces, internal file paths, or database error details to end users - configure generic error pages for production and route the actual detail to internal logging only, since verbose errors are a common, low-effort reconnaissance source for attackers.
6. Check for open cloud storage specifically (S3 buckets, Azure Blob containers, GCS buckets set to public) as a recurring automated check - this single misconfiguration class has caused a disproportionate share of real-world large data exposures and is trivially detectable with existing free scanning tools.

Using libraries, frameworks, or components with known vulnerabilities, often because there's no inventory of what's actually running in production.

1. Maintain a software bill of materials (SBOM) for every application, and separately inventory infrastructure-level software (OS versions, container base images, network appliance firmware) - application SCA tools won't catch an outdated firewall or unpatched hypervisor.
2. Automate dependency scanning (SCA) in the build pipeline - GitHub's built-in Dependabot, Snyk, or OWASP Dependency-Check are all reasonable starting points - configured to fail or flag the build on new critical/high findings, not just generate a report no one reads.
3. Cross-reference newly-disclosed vulnerabilities against CISA's Known Exploited Vulnerabilities (KEV) catalog specifically, not CVSS score alone - a medium-severity, actively-exploited CVE warrants faster remediation than a critical-severity one with no known exploitation.
4. Patch or replace end-of-life components on a defined schedule, and track time-to-patch once a fix exists as a real metric - the Equifax breach (see Case Studies) is the canonical example of a patch existing for months before exploitation; the gap that mattered was the delay applying it, not the vulnerability itself.
5. Subscribe to vendor security advisories and CVE feeds for every component actually in use, rather than relying on periodic manual checks - for anything internet-facing, the gap between disclosure and mass exploitation attempts is often measured in days.
6. For container images specifically, scan base images and layers before deployment (Trivy, Grype, or your registry's built-in scanning on ECR/GCR/ACR) and re-scan on a recurring schedule even for unchanged images - new CVEs are disclosed against existing software constantly.

Weak session management, missing account lockout, or lack of MFA allows attackers to compromise accounts through credential stuffing or brute force.

1. Enforce MFA everywhere feasible, prioritized by risk: start with admin/privileged accounts and anything reachable from the internet (VPN, RDP gateways, cloud consoles) via a Conditional Access policy in Entra ID (or equivalent), then extend to all users. For legacy apps without native MFA support, front them with an MFA-capable reverse proxy or ZTNA product rather than leaving them permanently exempt.
2. Set an account lockout policy that balances brute-force protection against denial-of-service risk - a common baseline is 5-10 failed attempts within a 15-minute window with a resetting counter, configured via Default Domain Policy → Account Lockout Policy in Active Directory, or the equivalent smart-lockout setting in Entra ID/Okta.
3. Rate-limit authentication endpoints at the application or WAF layer (a rate-based rule on the login endpoint in Cloudflare/AWS WAF) - account lockout alone doesn't stop distributed credential-stuffing spread thin across many accounts.
4. Rotate and invalidate session tokens on password change, not just at explicit logout - a compromised session token otherwise survives a password reset - and set short re-authentication intervals for high-privilege sessions rather than defaulting to long-lived "remember me" everywhere.
5. Eliminate default credentials on every deployed system before production, including network gear, IoT/OT devices, and management interfaces, not just applications - track this as a deployment-checklist item, not a one-time audit.
6. Check new or changed passwords against a breach-password list (e.g. the Have I Been Pwned Pwned Passwords API, which several IdPs and password managers integrate natively) so a password already circulating in a public breach corpus is rejected even if it meets complexity rules.

Code or infrastructure relies on plugins, libraries, or updates from sources that aren't verified for integrity, allowing a compromised upstream source to inject malicious code.

1. Verify digital signatures on software updates and dependencies before deployment where the ecosystem supports it (npm package provenance/Sigstore, GPG-signed OS packages) rather than trusting an unsigned download by URL or filename alone.
2. Use dependency-pinning and lockfiles (package-lock.json, pinned requirements.txt, Gemfile.lock) rather than automatically pulling the latest version on every build - an unpinned build is reproducible only by luck, and a compromised upstream release reaches you the moment it's published.
3. Restrict CI/CD pipelines from pulling unverified third-party packages: use a private package registry/proxy (Artifactory, Azure Artifacts, or npm/PyPI's own scoped-registry features) that only serves vetted versions, rather than pulling directly from the public registry on every build.
4. Protect CI/CD pipeline configuration itself from unauthorized modification - require review before merging changes to build/deploy scripts, since a modified pipeline file is a documented real-world path for injecting malicious code into an otherwise-clean codebase (the SolarWinds pattern - see Case Studies).
5. Apply integrity checks (checksums/hashes) to deployment artifacts at each handoff point in the pipeline - verify the artifact deployed to production is byte-for-byte the one that was built and scanned, not something substituted in transit.
6. Avoid insecure deserialization of untrusted data, and where deserializing external input is unavoidable, use a format/library that doesn't support arbitrary object instantiation (prefer JSON over language-native serialization like Python pickle or Java native serialization for anything externally-supplied).

Insufficient logging, or logs that aren't monitored, means breaches go undetected for long periods and can't be reconstructed after the fact.

1. Centralize logs in a SIEM or log-aggregation platform (Microsoft Sentinel, Splunk, Elastic, or a lighter option like Datadog) with alerting thresholds defined for specific conditions - not just raw retention with no one watching it.
2. Log authentication events, access-control failures, and input-validation failures specifically - at minimum every failed login, every privilege-escalation attempt, every 401/403 response, and every input rejected by validation logic (a burst of rejected input from one source is a stronger injection-attempt signal than any single request).
3. Set specific, actionable alert rules rather than "alert on everything": a practical starting set is 5+ failed logins for one account within 10 minutes, a successful login from an impossible-travel location, and a spike in 403/500 responses from one source IP - tune thresholds against your own baseline rather than using defaults blindly.
4. Forward logs to the SIEM in near-real-time rather than end-of-day batch collection, and use write-once/immutable log storage where the platform supports it - a local Windows Event Log with no forwarding is trivially cleared by an attacker with local admin (wevtutil cl ) before anyone notices.
5. Retain logs long enough to cover realistic dwell time, not just a compliance minimum - ransomware and BEC incidents commonly show weeks of attacker presence before the visible trigger event, and 30 days is often not enough to reconstruct the actual entry point.
6. Test detection coverage with periodic red-team, purple-team, or even a simple tabletop walkthrough - simulate a failed-login burst and confirm the alert actually fires and reaches a real person. A SIEM with no verified alert path is functionally the same as no SIEM.

An application fetches a remote resource without validating the user-supplied URL, letting an attacker force the server to make requests to internal systems it shouldn't reach.

1. Validate and allow-list destination hosts/IPs for any server-initiated request built from user input (webhook URLs, "fetch this image" features, PDF-generation-from-URL) - reject anything not on the explicit allow-list rather than deny-listing known-bad ranges, which is reliably bypassed via DNS rebinding or alternate IP encodings.
2. Specifically block requests to RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.1), and link-local addresses (169.254.0.0/16) at the application layer, in addition to any network-level control - this is the exact range attackers target to reach internal services from a vulnerable server-side request.
3. Block outbound requests to cloud metadata endpoints specifically (169.254.169.254 for AWS/Azure/GCP) - the single highest-value SSRF target in cloud environments, since it can return temporary credentials for the instance's IAM role, turning an SSRF into a full account compromise.
4. Segment internal services from the network zone that processes external requests, so a successful SSRF against the public-facing app has a limited set of reachable internal targets rather than open access to the whole internal network.
5. Disable unnecessary URL schemas (file://, gopher://, dict://) and disable automatic redirect-following, or re-validate the destination after each redirect hop, in the HTTP client library performing the server-initiated fetch - redirect chains are a common technique to bypass an initial allow-list check.
6. Use a dedicated network egress proxy for server-initiated outbound requests where feasible, so allow-listing and logging happen in one enforced choke point rather than being reimplemented (and potentially forgotten) in every feature that makes an outbound call.

Crafted input, either direct from a user or indirectly embedded in retrieved content, overrides the model's intended instructions and causes it to perform unintended actions or reveal restricted information.

1. Segregate untrusted external content from system instructions structurally, not just by prompt wording - use the distinct message roles your model API supports (system vs. user vs. tool/retrieved-content) so retrieved or user-supplied text is never concatenated into the same channel as your actual instructions.
2. Apply output filtering and require human-in-the-loop approval for any sensitive or irreversible action (sending an email, executing a transaction, modifying data) the model's output could trigger - never let model output directly execute a consequential action without a checkpoint.
3. Constrain model behavior via system prompts and expected output formats (e.g. requiring structured, schema-validated output) so an injected instruction has a harder time producing output your downstream code will actually act on.
4. Apply the same input-validation discipline to content the model retrieves (RAG sources, tool results, scraped web content) as to direct user input - indirect prompt injection via poisoned retrieved content is a documented attack path distinct from direct user prompts.
5. Grant the model/agent the minimum tool access and permissions actually needed for its task, since a successful injection can only do as much damage as the permissions available to whatever it's able to trigger.
6. Treat this class of attack as not fully solvable by prompt wording alone - combine structural segregation, output validation, least-privilege tool access, and human approval for high-impact actions, since each individual mitigation has documented bypasses on its own.

The model exposes personal data, credentials, or proprietary information in its output, either because it was present in training/context data or because output isn't filtered before returning to the user.

1. Apply data minimization - don't include sensitive data (PII, credentials, proprietary source) in context/prompts unless strictly necessary for the task, since anything placed in context is a candidate for the model to echo back, intentionally or not.
2. Filter and redact model output before it reaches the end user - a PII-detection/redaction pass (regex-based for structured formats like SSNs/card numbers, or a dedicated tool like Microsoft Presidio) on outbound responses, especially for features that summarize or process documents that may contain sensitive data.
3. Isolate retrieval-augmented generation (RAG) sources by the requesting user's actual access level, not just topical relevance - a RAG system retrieving from a shared index without per-document access control will surface content to users who shouldn't see it, even if the underlying documents have separate permissions in their source system.
4. Disable or restrict model training/fine-tuning on user-submitted content by default, and make any opt-in explicit and clearly disclosed - accidental inclusion of sensitive user input in a future training set is a durable, hard-to-reverse disclosure.
5. Set explicit system-prompt instructions and, where the platform supports it, output-format constraints that prevent the model from repeating back system prompts, internal configuration, or another user's context in a shared/multi-tenant deployment.
6. Audit logs and transcripts on a recurring basis, not just after an incident, for accidental sensitive-data echoes - a routine sample review catches disclosure patterns before they're reported by a user or discovered externally.

Third-party models, datasets, or plugins introduce vulnerable or malicious components into an AI pipeline - the same behavioral pattern as traditional software supply-chain risk, extended to model weights and training data.

1. Source models and datasets only from vetted repositories with verifiable provenance (Hugging Face's signed-commit and model-card provenance features, or a vendor's official model registry) rather than an unofficial mirror or an unverified upload.
2. Scan model files for unsafe deserialization risks before loading - a pickle-format model file can execute arbitrary code on load, so prefer safetensors or another format that doesn't support arbitrary object instantiation, and scan anything still in pickle format (e.g. Hugging Face's built-in Pickle Import scanner, or picklescan).
3. Maintain an AI bill of materials tracking model provenance, version, license, and training-data source for every model in use, the same way a traditional SBOM tracks software dependencies - this is what lets you actually respond when a specific model or dataset is later found to be compromised or mislicensed.
4. Pin specific model versions in production rather than auto-updating to "latest" - a model update can silently change behavior (including safety behavior) in ways a traditional dependency update wouldn't, so treat model version changes as a reviewed deployment, not an automatic pull.
5. Vet third-party plugins, tools, and agent extensions with the same scrutiny as a code dependency - a plugin with broad tool access is effectively new code running with the agent's permissions, and should go through the same review as any other third-party integration.
6. Apply integrity checks (checksums/hashes) to model artifacts at deployment time, matching the pattern used for traditional software artifacts, so the model actually loaded into production is verified to be the one that was reviewed and approved.

Manipulated training, fine-tuning, or embedding data introduces hidden backdoors, bias, or degraded behavior that activates under specific triggering conditions.

1. Validate the provenance and integrity of every training and fine-tuning data source before use - know specifically where each dataset came from and whether it's passed through any untrusted intermediate step; scraped web content and crowdsourced/user-submitted data carry materially higher poisoning risk than a curated, access-controlled internal source.
2. Restrict who can contribute to training/fine-tuning datasets with the same access-control discipline applied to production code - a poisoned dataset is functionally equivalent to a malicious code commit, and should require review before being incorporated.
3. Hold out a portion of training data for adversarial review, and specifically look for anomalous or duplicated patterns that could indicate a deliberately-inserted trigger, rather than assuming a large dataset is safe by volume alone.
4. Test models against known trigger-pattern categories before deployment (specific unusual phrases, formatting, or input sequences designed to activate a backdoor) as part of pre-deployment evaluation, not just standard accuracy/quality benchmarks.
5. Monitor production model outputs for behavioral drift from an established baseline on an ongoing basis, not just at initial deployment - a poisoning trigger may be designed to activate only under specific conditions that don't show up in routine testing.
6. If fine-tuning on user-submitted or feedback data in a continuous-learning setup, rate-limit and review the influence any single source can have on the model - an unlimited feedback loop from a small number of accounts is a documented path to gradually poisoning model behavior over time.

An AI agent is granted more autonomous permissions, tool access, or ability to take real-world action than its task actually requires, so a manipulated or malfunctioning agent can cause outsized damage.

1. Grant agents least-privilege access to tools and systems, scoped per task rather than a broad standing credential - an agent that only needs to read calendar data shouldn't also hold write access to email or file storage just because it's convenient to provision once.
2. Require explicit human approval for irreversible or high-impact actions specifically (sending external communications, financial transactions, deleting data, modifying access permissions) - define this list concretely per deployment rather than leaving "high-impact" as a vague judgment call the agent itself makes.
3. Log every tool call an agent makes, with the reasoning/prompt context that triggered it, in a format a human can actually review after the fact - this is what makes an agent's actions auditable rather than a black box, and is essential for diagnosing when something goes wrong.
4. Set hard rate and scope limits on what an autonomous agent can execute unsupervised within a given time window (maximum number of actions, maximum monetary value if it can initiate transactions) as a backstop independent of the agent's own reasoning, since a malfunctioning or manipulated agent can otherwise take many actions very quickly before a human notices.
5. Isolate agent execution environments (sandboxed containers, restricted service accounts) from broader production systems, so a compromised or malfunctioning agent's blast radius is contained to what it was actually provisioned to touch.
6. Periodically review and prune the actual permissions granted to each agent against what it's genuinely used in practice - agent tool access tends to accumulate over time the same way human account permissions do, and needs the same recurring review.

Uncontrolled or excessive requests to a model cause runaway computational cost, resource exhaustion, or denial of service - extended to include financial cost, not just availability.

1. Apply rate limiting and per-user/per-key quotas on model API calls, scaled to realistic usage patterns rather than a single global limit - a per-key quota stops one compromised or abused credential from consuming the entire budget/capacity available to every other user.
2. Set maximum token/context limits per request, and specifically cap the size of any user-controllable input included in context (uploaded documents, retrieved search results) - an unbounded input size is a direct unbounded-cost vector even without malicious intent.
3. Monitor cost and usage in real time with automatic circuit breakers that pause or throttle a specific key/user when spend crosses a defined threshold within a time window, rather than discovering a runaway cost spike only when the monthly bill arrives.
4. Isolate high-cost operations (large-context requests, multi-step agent chains, image/video generation) behind additional authorization checks or a separate, more tightly-quota'd tier, rather than exposing them at the same access level as routine low-cost requests.
5. Set hard ceilings on recursive or chained model calls specifically (an agent calling itself, or a workflow that can trigger further model calls based on its own output) - an unbounded chain is one of the more common ways a single request turns into runaway cost or resource exhaustion.
6. Alert on anomalous usage patterns per account (a sudden large increase in request volume or average request size relative to that account's own baseline), which catches both abuse and legitimate-but-costly misconfigurations before they become a large bill or a denial-of-service condition.