Low-Code and No-Code Security Guide: OWASP LCNC Top 10

Low-code and no-code apps leak data less through clever exploits than through ordinary choices: a maker's own credentials baked into a shared connection, a public endpoint left at the platform default, a connector that moves customer records to a personal mailbox. These apps are built outside the software development lifecycle by people who are not security specialists, often in large numbers, and they run with real access to business systems. OWASP's project for this space started as the Low-Code/No-Code Top 10 and is now published as the OWASP Citizen Development Top 10, widened to cover AI-assisted coding and AI agents. This guide works through the ten risks with platform-level controls, using Microsoft Power Platform as the worked example because its controls are well documented, and gives a rollout plan, detection approach and metrics. It is for security architects, platform administrators and application security teams. Programme and governance design is covered in the Citizen Developer and Internal AI App Governance Guide; this page is about securing the apps themselves.

Key takeaways

Identity is the core LCNC risk. When an app runs on its creator's identity or a shared connection, every user acts as the creator, audit logs show one actor, and least privilege is lost (CD-SEC-02, CD-SEC-03).
Govern connectors, not apps. Platform data policies that classify connectors and block risky ones scale to thousands of apps in a way that per-app review never will.
Platform defaults decide exposure. Public endpoints, anonymous access and broad sharing are settings, so tenant-level configuration needs change control and drift monitoring (CD-SEC-07).
Inventory before anything else. Ownerless, orphaned apps with live connections are the norm without a governance centre that records owner, data and risk tier (CD-SEC-09).
OWASP names the list differently now. The current IDs are CD-SEC-01 to CD-SEC-10, and the new first risk, Blind Trust, covers uncritical acceptance of platform and AI output.

The OWASP Citizen Development Top 10 at a glance

The OWASP project page (checked 27 October 2026) describes the list as originally focused on low-code/no-code platforms and now covering business innovation platforms, AI-assisted coding and AI agents. The table maps each risk to the platform control that most directly reduces it.

ID and risk	What goes wrong in LCNC apps	Primary platform control
CD-SEC-01 Blind Trust	Makers accept platform defaults, marketplace components and AI-generated logic without verification	Secure-by-default templates, pre-deployment validation, just-in-time guidance
CD-SEC-02 Account Impersonation	Apps embed the creator's credentials or a shared account, so all users act as the creator	Per-user (OAuth delegated) connections; dedicated, monitored service accounts for shared apps
CD-SEC-03 Authorization Misuse	Over-broad scopes and implicitly shared connections let users reach data they should not	Least-privilege connection scopes, restricting connection sharing, periodic re-authentication
CD-SEC-04 Sensitive Data Leakage and Handling Failures	Data flows to unapproved services, multi-hop paths and personal accounts	Connector data policies, approved connector list, restricted custom connectors
CD-SEC-05 Authentication and Secure Communication Failures	Personal credentials, plaintext secrets, disabled certificate validation	Restrict who can create production connections; secure connection templates
CD-SEC-06 Vulnerable and Untrusted Components	Insecure sub-workflows and marketplace components replicated across apps	Curated component library, documented input and output contracts
CD-SEC-07 Security Misconfiguration	Auto-generated APIs left public, weak app password rules, uploads not scanned	Tenant configuration baseline, change management and drift monitoring
CD-SEC-08 Injection Handling Failures	User input used unsanitised in queries, commands or platform formula syntax	Parameterised queries, platform-aware sanitisation, review of generated code
CD-SEC-09 Asset Management Failures	Ungoverned, unpatched and orphaned apps and flows	Central governance centre, ownership and lifecycle, tiered risk classification, inventory
CD-SEC-10 Security Logging and Monitoring Failures	No audit trail, or over-logging of raw sensitive data during debugging	Platform audit logs into the SIEM; logging settings that exclude raw application data

Identity, connections and shared credentials

OWASP describes CD-SEC-02 as apps blurring the line between their own identity and the identities of the people and services they connect to. A maker builds an app that reads a database using their own login, shares it, and from then on every user queries the database as the maker. Security tools see a single actor, and any user who can manipulate the app can reach whatever the maker can.

Know which connections travel with the app

Microsoft's Power Apps documentation shows how this happens in practice. When a canvas app is shared, some connections are implicitly shared with the recipients: SQL Server connections using SQL or Windows authentication are shared with the app, while Dataverse, OneDrive for Business and SQL Server with Microsoft Entra authentication require each user to create their own connection and hold their own permissions. The maker sees an implicit-permission warning and confirms it. Every implicitly shared connection is a non-human credential exposed to everyone the app is shared with.

Prefer delegated, per-user connections: use connectors that authenticate each user (OAuth or Entra) so the data source enforces the user's own permissions and logs the real actor.
Where a shared identity is unavoidable: use a dedicated service account per app with the narrowest database or API role, never a person's account, and monitor it as a privileged identity. OWASP recommends dedicated behaviour monitoring for these accounts. See the Service Account Security Guide.
Restrict connection creation in production: CD-SEC-05 recommends limiting new production connections to authorised personnel, which stops personal credentials entering shared environments.
Watch OAuth scopes: monitor for apps requesting highly privileged scopes unrelated to their purpose, and re-authenticate long-lived connections on a schedule (CD-SEC-03). The SaaS and OAuth App Governance Guide covers consent review.
Keep the audit trail attributable: if a shared connection is used, log the end user inside the app so actions can be traced to a person.

Data policies and connector governance

CD-SEC-04 recommends limiting connectors to an approved list, limiting custom connector creation to dedicated personnel and monitoring data flows that leave the organisation, including multi-hop paths. Platform data policies are how you do that at scale. In Power Platform, data policies (Microsoft now uses this name for what were DLP policies) govern connector use in Power Apps, Power Automate and Copilot Studio:

Three groups: connectors are classified as Business, Non-Business or Blocked. Connectors in different groups cannot be combined in one app or flow, so classifying SharePoint as Business and a personal email connector as Non-Business stops a flow copying one to the other.
Default group: new connectors land in the policy's default group. Microsoft's guidance is to keep Non-Business as the default and move connectors to Business or Blocked after evaluating them.
Nonblockable connectors: core connectors such as Dataverse, SharePoint, Teams, Outlook and OneDrive for Business can be classified but not blocked under classic data policies.
Enforcement: a blocked connector stops makers saving apps or flows that use it, and existing resources that violate a policy are suspended or quarantined. Enforcement usually completes within an hour, and can take up to 24 hours.
Custom and HTTP connectors: these are a common exfiltration path (ATT&CK T1567 Exfiltration Over Web Service) and should be blocked by default, with exceptions approved by the platform team.

Environment	Suggested connector stance	Sharing stance
Personal productivity (default environment)	Strict: Microsoft 365 connectors only as Business; social, consumer storage and HTTP blocked	Exclude sharing with security groups; small cap on individuals
Departmental	Approved business connectors; custom connectors only from the platform team	Group sharing allowed within the department
Production or business-critical	Explicit allowlist; connection creation limited to the owning team or service accounts	Managed by the owning team with change control

Managed Environments add sharing limits: administrators can prevent canvas apps being shared with security groups or with everyone, cap the number of individuals, turn off sharing of solution-aware cloud flows and restrict agent sharing. Microsoft notes these rules apply when someone tries to share and do not revoke existing access, so audit current sharing separately. The Microsoft Dynamics 365 and Power Platform Security Guide covers the wider tenant.

Public endpoints and platform misconfiguration

CD-SEC-07 gives the scenario of a platform auto-generating a REST endpoint for a web form that is publicly accessible without authentication by default. OWASP cites UpGuard's research into Power Apps portals, where default permissions exposed large volumes of records. Today Power Pages requires table permissions for lists, forms, Liquid templates and the Portals Web API to read Dataverse data, and each permission must be tied to a web role. The danger is in how they are granted:

Global access applies to all records in the table for every user in the web role. Granting it to an anonymous or broadly assigned role publishes the table.
Contact, Account and Self scope records to the signed-in user's contact, account or own record, and are the right default for customer-facing portals.
Review the Web API: enabling the Portals Web API for a table exposes it programmatically to anyone holding the role, so test it directly, not only through the page.

Across platforms (Salesforce Experience Cloud, ServiceNow portals and similar), the same pattern applies: find every externally reachable surface, list the roles that reach it, and check guest or anonymous access to data objects. See the Salesforce Security Guide and ServiceNow Security Guide. Build a tenant configuration baseline, put tenant-level settings under change management, and monitor for drift, as OWASP recommends.

Inventory, lifecycle and components

Governance centre: CD-SEC-09 recommends a central governance centre, enforced ownership and lifecycle, tiered risk classification, version control and a comprehensive inventory of apps, components and users. In Power Platform, the admin centre inventory and usage insights for Managed Environments are starting points.
Risk tiers: classify by data sensitivity, audience (personal, team, organisation, external) and connector set. Tier 1 apps (external audience or regulated data) get security review before go-live; tier 3 personal apps get automated policy checks only.
Orphans: when an owner leaves, reassign or retire their apps and flows. Their connections often still work and still carry their access.
Components: CD-SEC-06 warns that insecure sub-workflows and marketplace components are copied from app to app. Publish a curated library of secure components with documented inputs and outputs, and treat marketplace items as third-party code.
Injection: CD-SEC-08 recommends parameterised queries for SQL, sanitising platform-specific formula and expression syntax, and validating any code a coding agent generates. Low-code does not remove injection; it moves it into formulas and connectors.

Phased rollout

Discover: export the inventory of environments, apps, flows, connectors and connections. Flag implicitly shared connections, apps shared with everyone, custom and HTTP connectors, and anonymous portal roles.
Protect the default environment first: apply a strict data policy to the default or personal environment where most makers start, and add sharing limits.
Classify connectors in audit mode: review which apps would break under the proposed policy before enforcing, and contact owners. Remember enforcement suspends violating apps.
Fix identity: move high-risk apps from maker credentials to per-user connections or dedicated service accounts; rotate any credentials found embedded.
Introduce tiers and review: require security review for tier 1 apps, provide templates for authentication and data access, and enable pre-deployment checks where the platform supports them.
Monitor and iterate: stream platform audit logs to the SIEM and review new connectors, new external sharing and new public endpoints weekly.
Rollback: if an enforced policy breaks a critical process, grant a time-limited exception for that environment, not a tenant-wide change, and record the owner and expiry.

Detection and measurement

CD-SEC-10 identifies two failure modes: no audit trail at all, and over-logging of raw data during debugging. Collect platform user access and audit logs, and configure application logging so it does not capture raw sensitive data.

Alert on: new custom or HTTP connectors, apps newly shared with everyone or external users, connections created with personal accounts in production environments, table permissions granting Global access to anonymous roles, and flows that forward mail or files outside the organisation.
Service account behaviour: baseline the volume and targets of each shared connection's service account and alert on deviation (ATT&CK T1078 Valid Accounts).
Data policy violations: suspended or quarantined apps and flows are a signal of either shadow use or a policy gap.

Metrics

Percentage of apps and flows with a named, active owner and a risk tier.
Number of implicitly shared connections and apps running on maker credentials (trend to zero for tier 1 and 2).
Percentage of environments covered by a data policy, and connectors in the Business group reviewed in the last 12 months.
Count of externally reachable surfaces with anonymous or Global data access.
Median days to retire or reassign apps after their owner leaves.

Framework mapping

LCNC control	NIST SP 800-53 Rev 5	NIST CSF 2.0	OWASP CD-SEC
Per-user connections, dedicated service accounts	AC-2 Account Management, AC-6 Least Privilege	PR.AA-05	CD-SEC-02, CD-SEC-03
Connector data policies	AC-4 Information Flow Enforcement	PR.AA-05	CD-SEC-04
Portal table permissions and web roles	AC-3 Access Enforcement	PR.AA-05	CD-SEC-07
Inventory and lifecycle	CM-8 System Component Inventory	ID.AM-02	CD-SEC-09
Audit logs to SIEM	AU-2 Event Logging, AU-6 Audit Record Review	DE.CM-09	CD-SEC-10
Secure templates and pre-deployment validation	SA-8 Security and Privacy Engineering Principles	PR.PS-06	CD-SEC-01, CD-SEC-06

Common failure patterns

Sharing an app that carries the maker's database login: an implicitly shared SQL connection gives every user the maker's access, with logs that point at the maker.
Leaving the default environment open: most citizen development starts there, so a permissive or missing data policy on it undoes stricter policies elsewhere.
Granting Global read to make a portal list work: the quickest fix for an empty list in a portal is also the one that publishes the whole table.
Assuming sharing limits are retroactive: Managed Environments sharing rules apply at the next share attempt, so over-shared apps stay over-shared until someone audits them.
Allowing HTTP and custom connectors everywhere: they bypass connector classification as a route to any external endpoint. Block by default and approve case by case.
Treating AI-generated logic as reviewed: CD-SEC-01 and CD-SEC-07 both describe makers deploying generated code with insecure defaults. Apply the same checks as for any code; see the Vibe Coding Security Guide.

Practitioner checklist

A complete inventory of environments, apps, flows, connectors and connections exists, with owner and risk tier for each app.
Every environment, starting with the default environment, has a data policy; HTTP and custom connectors are blocked unless approved.
Apps shared beyond their maker use per-user connections or a dedicated, least-privilege service account, never a person's credentials.
Implicitly shared connections are reviewed and justified, and their credentials are rotated.
Sharing limits prevent sharing with everyone in personal and departmental environments, and existing over-sharing has been audited.
Portal and external surfaces use scoped table permissions (Contact, Account, Self), with no Global access for anonymous roles.
Tenant-level settings are under change management and monitored for drift.
Platform audit logs reach the SIEM, with alerts for new connectors, external sharing and public endpoints.
Orphaned apps are reassigned or retired within a defined period after the owner leaves.

Low-Code and No-Code Application Security Guide: OWASP LCNC Top 10