OWASP citizen development top 10

The OWASP Citizen Development Top 10 is OWASP’s answer to a question most security teams are only starting to ask, which is what happens when everyone in the company can build software. The project grew out of the earlier Low-Code/No-Code Top 10 and broadened its scope to cover the full set of technologies behind citizen development, meaning low-code and no-code platforms, AI-assisted coding tools, and AI agents.

This guide walks security, platform, and governance teams through all ten risk categories, labeled CD-SEC-01 through CD-SEC-10. For each one you get a plain description, the scenarios that matter most, and the controls that do the heaviest lifting. If AI-built software is your larger concern, read this alongside our guides to the OWASP LLM Top 10 and the OWASP Agentic Top 10, which cover the model and agent layers in depth.

What Is the OWASP Citizen Development Top 10?

The OWASP Citizen Development Top 10 is a community-built list of the ten security risks most likely to compromise software created by citizen developers, the business users and hobbyists who build applications without formal engineering training. Gartner coined the citizen developer term back in 2009, and platforms such as Power Platform, ServiceNow, and Salesforce, along with AI tools like Cursor and Replit, have since turned that idea into a daily reality inside most enterprises.

The list speaks to three audiences at once, and that framing shapes every entry. Security professionals get the guardrails they need to enable safe adoption, citizen developers get an honest picture of how their shortcuts create risk, and governance bodies get structured recommendations for oversight. The stated mission is to let innovation thrive without surrendering security, and the crossover focus throughout the document is collaboration between the business, security, and governance.

From the Low-Code/No-Code Top 10 to the Citizen Development Top 10

The project began life as the OWASP Low-Code/No-Code Top 10, with risk IDs carrying the LCNC-SEC prefix. As AI assistants and autonomous agents joined drag-and-drop platforms as common ways for non-engineers to ship software, the maintainers widened the lens and relabeled every entry under the CD-SEC prefix. The current edition therefore treats business innovation platforms, AI-assisted coding, and AI agents as one connected risk surface rather than three separate problems.

Why the Citizen Development Top 10 Matters Now

The Citizen Development Top 10 matters because software creation has escaped the engineering organization, while most security programs still assume every application passes through one. Every finance analyst with a workflow builder and every product manager with a coding assistant now ships logic that touches real data. Cycode’s State of Product Security 2026 research found that 81% of organizations lack full visibility into how AI is used across the SDLC.

Every employee can now ship software

Citizen developers optimize for the task in front of them, which means speed and convenience win most tradeoffs. The OWASP project documents the cognitive biases behind this, including automation bias, where platform output is treated as inherently safe, the availability heuristic, where accessible code beats optimal code, and anchoring bias, where the first template presented becomes the final design. None of these habits are malicious, yet each one quietly accumulates organizational risk.

The risks have already produced real breaches

The document closes with incidents that show these categories at work. The 2021 Microsoft Power Apps Portals leak exposed roughly 38 million records, including Social Security numbers, because a default-off permission setting left backend data anonymously accessible across dozens of organizations. In 2025, no-code app builder Passion.io exposed more than 3.6 million records through an unprotected database. Neither failure required an exploit, since both grew out of default settings that nobody thought to question.

The OWASP Citizen Development Top 10 Risks Explained

Below is a category by category walkthrough of all ten risks. Each entry gets a plain description drawn from the official document, along with the preventions that carry the most weight in practice. Risk IDs run from CD-SEC-01 through CD-SEC-10, and OWASP treats the first entry as foundational to the other nine. The table gives the short version first, and the sections that follow add the detail security teams need to turn each category into policy.

CD-SEC-01: Blind trust

Blind trust is the uncritical acceptance of whatever a platform, template, or AI model produces, without independent verification of its accuracy or security. OWASP treats it as the foundational entry because it amplifies every other risk on the list, and it is the only category with a dedicated framework, the Blind Trust Secure Framework. That framework rests on enforcing secure defaults, extending governance to every citizen-built application, and embedding just-in-time security guidance into the development flow.

• A marketplace login template can hide a credential-stealing script beneath a polished interface.
• AI-generated infrastructure code can hallucinate logic and silently grant overly permissive access.
• Pre-deployment review of generated code catches what the citizen developer cannot.

CD-SEC-02: Account impersonation

Citizen-built applications blur the line between the app’s own identity and the identities it connects with. Creators embed personal credentials, shared service accounts, or database connections for quick access, and every user of the application then acts under that embedded identity. Monitoring systems see one trusted user performing everything, which breaks audit trails and opens a direct path to privilege escalation, especially when a single application spans several platforms or environments.

• Replace creator identities with dedicated, monitored service accounts for shared applications.
• Apply least privilege to every database, SaaS, and service connection.
• Maintain audit trails that identify the real actor behind each action.

CD-SEC-03: Authorization misuse

Citizen development platforms make integration easy through pre-built connectors and reusable credentials, and that convenience is exactly where authorization misuse begins. OAuth tokens, refresh tokens, and API keys get stored broadly, shared across applications, and left active long past their intended lifecycle. Scopes are granted far wider than the task requires, and the result is an ecosystem of zombie connections that stay long-lived, over-privileged, and nearly impossible to monitor or revoke.

• Review every requested scope against the principle of least privilege.
• Refresh OAuth tokens regularly by forcing connections to re-authenticate.
• Monitor citizen development platforms for over-shared and abandoned connections.

CD-SEC-04: Sensitive data leakage and handling failures

Most citizen development tools cannot classify, tag, or track sensitive data through an application’s lifecycle, because they were designed for flexibility rather than governance. Sensitive information then leaks through misconfigured permissions, public storage, unsecured APIs, or AI-generated logic that transmits and logs data without protection. Undocumented dependencies between connected workflows add operational risk on top, since one upstream schema change can corrupt data across every downstream process that silently depends on it.

• Pasting raw support logs into an AI assistant can broadcast customer data company-wide.
• Exported app components can carry plaintext connection strings into shared drives.
• Approved connector lists and boundary monitoring contain data before it leaves.

CD-SEC-05: Authentication and secure communication failures

Citizen developers focus on making the connection work, and security settings become whatever gets them past the next error message. The document catalogs the familiar results, including personal passwords used in place of scoped API keys, disabled TLS validation, plaintext secrets, hardcoded bearer tokens, and HTTP endpoints where HTTPS belonged. Each weak connection persists quietly, and over time organizations accumulate ungoverned integrations that violate corporate policy and resist both detection and remediation.

• Restrict new production connections to authorized personnel and teams.
• Ship secure authentication templates so the compliant path is also the fastest one.
• Run continuous secrets detection across repositories, configuration files, and pipelines.

CD-SEC-06: Vulnerable and untrusted components

Nested sub-workflows, marketplace components, and AI-suggested packages all enter citizen-built applications with little vetting, and a single flawed component can replicate across an entire organization. The document calls out AI hallucination as a new supply chain twist, where an assistant invents a package that does not exist and an attacker registers that exact name with malicious code inside. Reused AI-generated snippets spread one vulnerability across every form that copies them.

• Verify every dependency with software composition analysis before it loads.
• Build standardized, vetted component libraries for common functionality.
• Hold sub-workflows to the same security controls as the parent application.

CD-SEC-07: Security misconfiguration

Configuration in citizen development often sits at the application level rather than the tenant level, which hands business users the authority to adopt insecure defaults. AI assistants compound the problem by delivering code that is functionally correct yet insecure by default, such as a logging function pointed at publicly accessible storage. The Power Apps incident lives in this category, where a single default-off table permission setting exposed millions of records to anonymous visitors.

• Create hardened templates so customization always starts from a secure baseline.
• Validate solutions before deployment and monitor configurations for drift afterward.
• Match tenant-level settings to vendor guidance and company password policy.

CD-SEC-08: Injection handling failures

Citizen-built applications routinely query data based on user input, and neither the platform, the AI, nor the developer reliably sanitizes that input first. Classic SQL injection applies in full, and the document adds a platform-specific twist, since low-code tools use proprietary syntax to reference internal data, and common sanitization libraries never account for it. An attacker who speaks that syntax can pull sensitive platform data straight through an innocent-looking public form.

• Sanitize user input against standard payloads and platform-specific syntax alike.
• Parameterize every database interaction instead of concatenating queries.
• Instruct AI assistants, through rules and system prompts, to generate validation logic.

CD-SEC-09: Asset management failures

The ease of citizen development produces volume, and volume produces orphans. Applications get built, shared widely, depended upon, and then abandoned without owners, patching schedules, or inventory entries, while every marketplace template a browsing developer clicks can spawn another external-facing URL. Shadow workflows built with AI assistance bypass review entirely, and when a flaw surfaces in a shared component, nobody can say which of hundreds of live apps contain it.

• Maintain a central inventory of applications, components, connections, and users.
• Enforce ownership and lifecycle policies, retiring whatever nobody claims.
• Classify applications into risk tiers so review effort matches real exposure.

CD-SEC-10: Security logging and monitoring failures

Logging in citizen-built applications swings between two failure modes. Under-logging leaves investigators blind during an incident, because critical actions were never captured and platform defaults recorded almost nothing useful. Over-logging, usually enabled for debugging and never switched off, captures sensitive runtime data and turns the logs themselves into a disclosure risk. Fragmented audit trails across integrated services then make reconstructing who changed what, and when, nearly impossible for responders.

• Collect platform audit logs and user access logs through built-in capabilities.
• Instrument applications for extra visibility where the platform falls short.
• Configure logging to exclude raw sensitive data from every record.

How to Mitigate the Citizen Development Top 10

No single control closes this list, and OWASP is explicit that training alone cannot fix it either. The through line across all ten entries is to govern citizen development as a managed extension of the official environment, applying the same inventory, identity, and review discipline that already covers engineering-built software. Three control families, drawn from the preventions throughout the document, deliver most of the available risk reduction for enterprise programs.

Make the secure path the easiest path

Citizen developers take the path of least resistance, so the secure option has to be the convenient one. That means secure-by-default platform configurations that are difficult to disable, vetted template and component libraries ready for immediate reuse, and just-in-time guidance delivered inside the development environment where decisions get made. Pre-deployment review of generated and modified code then closes the loop before anything insecure reaches real users.

• Ship hardened templates for logins, connections, and data handling.
• Embed security prompts and guidance where building happens.
• Gate deployment on automated static application security testing of generated code.

Govern identities, connections, and data flows

Most entries on the list trace back to identity and connection hygiene. Dedicated service accounts replace embedded personal credentials, OAuth scopes shrink to what each task requires, tokens rotate on a schedule, and connectors come from an approved list. Monitoring then watches for the drift that governance alone never catches, including over-shared connections, data moving outside organizational boundaries, and configurations sliding quietly away from the secure patterns they started with.

• Disable implicitly shared connections and monitor the ones that remain.
• Limit custom connector creation to dedicated, accountable personnel.
• Watch multi-hop data flows that cross the organizational boundary.

Keep an inventory and watch it continuously

Everything OWASP recommends assumes you know what exists, and most organizations do not. A centralized governance center, mandatory ownership, tiered risk classification, and lifecycle enforcement turn an unmapped sprawl into a managed portfolio that can be patched on schedule. An AI bill of materials extends the same discipline to the assistants, models, and agents doing the building, which is where the list’s newest scenarios concentrate.

• Inventory every application, component, connection, and creator.
• Record which AI tools and agents contributed to each solution.
• Audit the portfolio on a cadence matched to its risk tier.

How Cycode Helps You Address the Citizen Development Top 10

Cycode is the Agentic Development Security Platform, built for the world this OWASP list describes, where developers and citizen developers ship software alongside AI agents. ADLC Security governs the AI layer where citizen development now happens, while the platform’s ASPM foundation supplies the inventory, prioritization, and posture visibility the list keeps demanding. Both run inside the workflows that builders of every skill level already use.

The practical effect is that the ten categories run as enforced policy instead of a checklist someone tracks by hand, from the workstation where a package gets installed to the pull request where generated code gets merged. Findings arrive correlated and routed to whoever owns the fix, so security teams keep control of the boundaries while the business keeps building at full speed, which is the balance the OWASP document asks for.

• Citizen Developer Security extends governance to low-code platforms, AI coding tools and the apps business users build, with the inventory, ownership and policy controls this list calls for.
• AI Visibility discovers the assistants, models, and citizen development tools already in use, including shadow AI nobody registered.
• AI Guardrails intercept risky prompts, file reads, and insecure patterns in the IDE and CLI before they ship.
• Workstation Protection blocks malicious and hallucinated packages at install time, on every developer machine.
• Agentic code scanning reasons across generated code to catch the logic flaws that rule engines structurally miss.
• Agentic Workflows put agents to work fixing risk the moment it appears, inside boundaries security teams define.
• Maestro orchestrates triage, exploitability checks, and PR-ready fixes by reasoning over the Context Intelligence Graph, so citizen-built risk stays correlated with the rest of your software factory.

Book a demo to see how Cycode secures every layer of the Agentic Development Lifecycle, from a citizen developer’s first prompt to production.