CCSP Application Security Awareness: Cloud Development Basics, Pitfalls and the OWASP, API, LLM and CWE Top Lists

In every cloud service model except SaaS, the security of the code a customer writes and deploys stays with the customer. The provider secures the layers it runs; the application's input validation, authorization logic, session handling, error handling, libraries and the access settings it gives its own identities are the customer's share. Application security awareness exists because that share is written by developers, and most of the flaws that breach cloud applications are introduced there rather than in the provider's infrastructure.

The split moves with the service model, and developers need to know exactly where it sits for the platform they deploy to:

Moving an application from IaaS to PaaS therefore changes only the operating-system and runtime row of the table: everything the team writes, bundles or configures stays with it. A common misunderstanding is that "the platform is managed" means "the application is managed".

Cloud development also changes how applications are built: almost everything is reached through APIs (the provider's management APIs and the application's own), infrastructure is defined as code, components are small services that call each other over the network, and deployments are frequent and automated. Each of these widens what a developer must understand — an API is an attack surface, a template is a configuration that can be wrong, and a service-to-service call can no longer assume a trusted network.

The common pitfalls are assumptions that held on premises, or that sound reassuring, but that the cloud breaks. The ones the CCSP outline has in mind are:

• Lift-and-shift trust assumptions. Legacy components often accept unauthenticated calls from any internal address because the data centre perimeter screened callers. Moving them unchanged to IaaS moves the code but not the perimeter it relied on, so components that authenticate nobody become exposed. Of all migration pitfalls this is usually the most significant security risk, because it is a direct, exploitable exposure: anyone who can reach the component can use it, with no further weakness needed.
• Overreliance on provider certifications. A provider's certifications and attestation reports describe the provider's own controls and the services in their scope. The customer's application code and configuration sit outside that scope, so whatever the provider holds, the application still needs its own security assessment. Risk acceptance does not close the gap either: a risk has to be identified and assessed before anyone can decide to accept it.
• Not every pitfall is a security pitfall. Migrations raise many genuine concerns — software licence terms written for physical hardware, performance of components that become distant from each other, portability, contractual exit terms. These are legal, cost or performance problems. When the question is specifically about security risk, weigh each concern by whether an attacker could exploit it, and keep the commercial and operational ones for the teams that own them.
• Insecure defaults left in place. Convenience settings from development — debug modes, sample accounts, permissive sharing, detailed error pages — that ship to production unchanged are a frequent cause of cloud data exposure.
• Treating integration data as trusted. Data returned by partner APIs, model output and content fetched from URLs is all untrusted input, however reputable its source.

The developer-facing lesson in each case is the same: identify what the old environment or a third party was silently providing, and build that control into the application itself.

An effective application security awareness programme is role-based, driven by the organization's own findings, and carried into daily work by people embedded in the teams. General annual security awareness training for all staff is necessary, but it does not teach developers to avoid the specific flaws they write.

• Start from evidence. When penetration tests or reviews keep finding the same flaw class (for example, authorization flaws), start by analysing those recurring findings: which flaw classes, in which teams, introduced by which roles. That analysis tells you what to teach and to whom, and gives you a baseline to measure the programme against. Content chosen without it tends to cover what is easy to buy rather than what your developers actually get wrong. Testing tools such as static analysis belong to sub-domain 4.4; they catch flaws after they are written and complement awareness rather than replacing it.
• Role-based content. Developers, architects, testers, operations staff and product owners need different material: secure coding patterns for developers, design and threat considerations for architects, verification standards for testers, configuration and deployment hygiene for operations.
• Scale with security champions. Awareness that depends on a handful of central specialists stops growing once their calendars are full. A security champion is a developer in each team, given extra training and a direct line to the central security team, who brings security into design discussions and code reviews as they happen and keeps knowledge current between formal sessions. The model scales with the number of teams instead of the size of the security team.
• Use the community lists as shared vocabulary. The OWASP and CWE lists below give developers names for the flaws they are learning to avoid, and give the programme a way to map findings to categories and track whether training changes them.
• Keep it continuous. Feed new findings, incidents and list updates (the OWASP Top 10, API and LLM lists are all revised over time) back into the content.

The lists named in the CCSP outline serve different purposes: the OWASP Top 10, the API Security Top 10 and the Top 10 for LLM Applications are awareness documents of risk categories; OWASP ASVS is a verification standard of testable requirements; and the CWE Top 25 (historically published with SANS, hence "SANS Top 25") is a data-driven ranking of weakness types. Choosing the wrong one for a job is a classic mistake.

No one is certified against the OWASP Top 10. OWASP describes it as an awareness document, and there is no Top 10 certification scheme. Because its categories are broad themes rather than requirements, "compliant with the Top 10" has no agreed test. When security has to be measurable — in a contract, a vendor assessment or a release gate — the requirements must be specific and testable, which is the job ASVS was written for.

The OWASP Application Security Verification Standard (ASVS) is a list of detailed, testable security requirements that teams use as a basis for designing, building and verifying applications. Because each requirement can be checked, ASVS works as acceptance criteria, as the scope of sign-off testing before a release, and as the yardstick in a contract or vendor assessment.

ASVS 5.0 (the current version) groups its requirements into three levels, each including the one below:

• Level 1 — the first layer of defence that every application should meet. ASVS 5.0 notes that Level 1 is not necessarily verifiable by black-box penetration testing alone; some requirements need access to code, configuration or documentation.
• Level 2 — the level ASVS 5.0 says most applications should be striving to achieve.
• Level 3 — for applications that must demonstrate the highest level of assurance, such as those protecting the most sensitive data or critical functions.

The standard leaves the choice to the organization: each application's level should come from an analysis of its risk, the sensitivity of its data and what its users expect. The level is a property of the application and what is at stake if it fails, so two applications on the same platform can rightly target different levels.

How ASVS is used in secure coding and in testing is taught in the sibling lessons on applying the SDLC (4.3) and on software assurance and validation (4.4); here the point is knowing what ASVS is and how it differs from the awareness lists.

The OWASP Top 10:2025 ranks ten web application risk categories, each mapped to a set of CWE weaknesses. The 2025 edition reorganised several categories, and the mappings matter because findings are classified by them:

Distinctions that decide the category

• Authenticated but reaching someone else's data is Broken Access Control, not an authentication failure — the login worked; the per-record authorization check is missing.
• SSRF has no category of its own in 2025. An application that fetches attacker-chosen URLs (for example, a webhook or image-import feature made to call internal-only addresses) is listed under Broken Access Control. Restricting what the server can reach on the network reduces impact but does not change where the code weakness is mapped.
• Open cloud storage is Security Misconfiguration. Data reaches unauthorised users, but OWASP explicitly places improperly configured cloud service permissions in A02. A protection that exists but was switched off or left at its default — including missing cookie attributes — is a misconfiguration rather than a cryptographic or design failure.
• Supply chain vs integrity. A03 covers compromise that enters through the dependency chain and build process (a hijacked maintainer account, an unpinned dependency that pulls a malicious release). A08 is the lower-level failure to verify the integrity of code or data the application trusts, such as unsigned updates or serialized session objects that a client can edit.
• Exceptional conditions are about how code reacts when something goes wrong. Code that treats an unavailable dependency — a policy engine that cannot be reached, a validation call that throws — as permission to proceed is failing open; the remedy is to fail closed. A multi-step operation that completes its first step, hits an error part-way and leaves the earlier steps in place instead of rolling them back is also A10. Unauthorised access or inconsistent records are the results; the root cause is the error path.

The OWASP API Security Top 10 (2023) is the awareness list for API risks, and cloud applications are mostly APIs. Its categories are: API1 Broken Object Level Authorization (BOLA), API2 Broken Authentication, API3 Broken Object Property Level Authorization (BOPLA), API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization (BFLA), API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management and API10 Unsafe Consumption of APIs.

Three of them are near-twins about authorization, separated by what the caller should not reach:

In every case the caller is authenticated, which is why Broken Authentication (API2) is rarely the answer for these findings.

Resource consumption vs business flows

API4 Unrestricted Resource Consumption is missing limits on what requests consume — compute, bandwidth, storage, or money spent on paid third-party services. OWASP's own scenarios include an endpoint that triggers a paid third-party service, such as SMS or email delivery, on every call with no limit. API6 Unrestricted Access to Sensitive Business Flows is automated abuse of a legitimate flow for its business outcome, such as bots on real accounts reserving every available appointment slot to sell them on, or mass-creating accounts to claim a sign-up bonus — even with no implementation bug and no strain on the service. A useful test: if the attacker wants the flow's result, it is API6; if they are burning resources or cost, it is API4.

Inventory and third-party data

• API9 Improper Inventory Management is about versions and hosts nobody tracks: a retired API version or a forgotten staging host that is still reachable and never received later fixes. You cannot secure an API you do not know is running. The root cause is the missing inventory: the exposure exists because nobody knows the version is still running.
• API10 Unsafe Consumption of APIs is trusting data from integrated third-party APIs more than user input — for example, following a partner's redirects blindly or processing its responses without validation, so that a compromise of the partner becomes a compromise of your application. This differs from API7 SSRF, where the attacker controls where the server sends requests.

The OWASP Top 10 for Large Language Model Applications (2025) is the awareness list for applications built on LLMs — chatbots, assistants, retrieval-augmented generation (RAG) and agents that call tools. Its categories are: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation and LLM10 Unbounded Consumption.

Cause vs consequence

Several categories describe a result (Sensitive Information Disclosure) while others describe the cause that produced it. When untrusted text changes what the model does and data leaks as a result, the cause is Prompt Injection. Classify by the weakness that must be fixed, not by the harm.

Controls that hold when injection succeeds

• Excessive Agency (LLM06). An LLM extension or plugin with more functionality, permission or autonomy than its task needs. For example, a scheduling assistant that only needs to read calendars but was given a connector that can also create invoices and change payment details turns any successful manipulation into a financial incident. Measures that make injection less likely are worth having, but none is reliable, so the control that bounds the damage is least privilege on the tools themselves: grant only the functions and permissions the task needs, and require human approval for high-impact actions. Assume injection will happen; limit what the model can do when it does.
• System Prompt Leakage (LLM07). Treat the system prompt as public: anything placed in it — an API key, internal business rules, details of how permissions work — should be assumed extractable. OWASP's guidance is that the system prompt must not be a security control and must not hold secrets; credentials belong in the application's secret storage, and authorization decisions belong in code outside the model, where a clever prompt cannot reach them.
• Improper Output Handling (LLM05). Model output passed downstream without validation or encoding — for example, handed to a shell, a database query or a page template, so that generated text becomes executed commands, SQL or script. The crafted request may be an injection, but the weakness to fix is trusting the output. Treat LLM output as untrusted input to whatever consumes it.
• Vector and Embedding Weaknesses (LLM08). Includes weak access partitioning in multi-tenant vector stores, where embeddings from several customers or permission groups share one store and retrieval does not filter by who is asking — so a user's normal query can pull back content they were never entitled to. The weakness is in how the store is partitioned, not in the data or the prompt. Multi-tenant RAG needs tenant isolation inside the vector store, not just at the application.
• Unbounded Consumption (LLM10). Uncontrolled inference use — requests that exhaust model capacity, run up pay-per-use inference costs ("denial of wallet"), or query the model at scale to extract its behaviour. Controls are input size limits, quotas and rate limiting. The CCSP outline's commentary on Domain 4 highlights exactly this pairing: input validation and rate limiting against prompt injection and automated resource exhaustion.

The CWE Top 25 Most Dangerous Software Weaknesses, published by MITRE (and long known as the CWE/SANS Top 25), ranks types of software weakness — such as cross-site scripting, out-of-bounds write or missing authorization — by how common and how severe they are in real vulnerability data. It gives an awareness programme a root-cause view: the kinds of mistake developers should learn to avoid.

How the ranking is built. The CWE Top 25 team takes published CVE records from the CVE Program and uses the root-cause CWE mappings provided by the CVE Numbering Authorities (CNAs) that published them, reviewing and remapping them where needed. Each weakness is then scored by multiplying its normalised frequency in that data by the normalised average CVSS base score of the CVEs mapped to it: the ranking is frequency times severity, computed from real vulnerability records. (OWASP builds its Top 10 differently, combining contributed testing data with a community survey for some categories.)

In the 2025 edition, cross-site scripting held the top position. Because the list is recalculated from new data, exact ranks move between editions; what stays stable is the method and the purpose.

Most questions on this topic describe a finding and ask which category it fits. A reliable way to classify is to separate the root cause from the consequence and then test the near-twin categories against the facts given.

1. Name the harm, then set it aside. Data disclosure, unauthorised access and runaway cost are usually consequences. Ask what weakness made them possible.
2. Ask who was trusted that should not have been. A caller with an identifier (object authorization), a role (function authorization), a field (property authorization), a dependency (supply chain), client-supplied serialized data (integrity), a partner API (unsafe consumption), model output (output handling) or a URL (SSRF).
3. Ask whether the protection existed. If a control is available but switched off or left at its default, it is a misconfiguration. If the code reacts badly only when something fails, it is mishandling of exceptional conditions. If the control was never designed, it is insecure design.
4. Test each near-twin against every fact. A category fits only if the scenario contains its defining condition. When a stated fact contradicts that condition, rule the category out, however close the harm looks.

Teaching developers this reasoning, rather than memorised lists, is the purpose of the awareness programme: it lets them recognise a new flaw by its cause. Avoiding these vulnerabilities during development (threat modelling, secure coding) is taught in the lesson on applying the secure SDLC (4.3); finding them with testing tools in the lesson on software assurance and validation (4.4); and API gateways, supply-chain assessment and verified components in the lesson on using verified secure software (4.5).