bcquality/microsoft/knowledge/security/internal-access-is-not-a-security-boundary.md
Jesper Schulz-Wedde e81632b4be Complete AL review knowledge readiness
Fill telemetry and Query coverage, strengthen thin review domains, correct audited content defects, and add deterministic cheap-model evaluation and reference-integrity safeguards.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27
2026-07-15 07:19:15 +02:00

1.5 KiB

bc-version domain keywords technologies countries application-area
all
security
access
internal
internalsvisibleto
recordref
codeunit-run
security-boundary
authorization
al
w1
all

Access Internal is API hygiene, not an authorization boundary

Description

Access = Internal controls compile-time symbol visibility. It does not prevent runtime access through mechanisms such as RecordRef, TransferFields, or Codeunit.Run, and internalsVisibleTo deliberately grants compile-time access to named companion apps. Microsoft explicitly documents that access modifiers cannot be used as a security boundary.

Best Practice

Use internal to keep implementation details out of the supported API, but enforce sensitive operations with permissions, entitlements, and explicit authorization checks appropriate to the operation. Treat internalsVisibleTo as a same-publisher development/testability relationship, not as a trust grant for secrets or elevated data access.

See sample: internal-access-is-not-a-security-boundary.good.al.

Anti Pattern

Placing privileged work in an internal codeunit and claiming that other extensions cannot invoke it, or exposing an app to a different publisher through internalsVisibleTo because internal is assumed to protect the underlying operation. The access modifier narrows supported callers; it does not authenticate runtime callers.

See sample: internal-access-is-not-a-security-boundary.bad.al.