Dynamic dispatch is a method of selecting which function or method implementation to run at runtime rather than at compile time. It is commonly used in object-oriented languages and other polymorphic systems, where the actual receiver type determines the call target.
How dynamic dispatch works
Dynamic dispatch is the mechanism that defers the choice of function or method body until runtime, so the actual object or receiver type determines which implementation executes. That makes it a core feature of polymorphism in object-oriented and interface-driven systems.
At a language level, dynamic dispatch is usually implemented through runtime metadata such as virtual method tables, interface tables, type tags, or equivalent lookup structures. The important idea is not the exact mechanism, but that the call target can change based on the runtime type rather than the static type seen by the compiler.
Why dynamic dispatch exists
Dynamic dispatch lets code work against an abstraction while still reaching the correct specialised behaviour for each concrete type. That improves extensibility, because new implementations can often be added without rewriting the code that invokes the method.
This is also what makes dynamic dispatch useful in framework, plugin, and callback patterns. The caller does not need to know every subtype in advance, only the contract that each implementation obeys. In practice, this reduces coupling between the code that triggers an action and the code that performs it.
Dynamic dispatch in design and performance
Dynamic dispatch is a design choice as much as a runtime mechanism. It supports substitution and late binding, but it also means the exact behaviour of a call is not always obvious from the source line alone, especially when inheritance hierarchies are deep or interfaces are widely reused.
Because the call target is resolved at runtime, dynamic dispatch can introduce a small performance cost compared with a direct call. Modern runtimes and JIT compilers often optimise common cases, but the overhead can still matter in tight loops, hot paths, or highly concurrent systems where method calls are frequent.
Failure modes and security-relevant implications
Most risks around dynamic dispatch come from incorrect assumptions about what implementation will run, or from abuse of the indirection it creates. If program logic depends on a specific subtype, a wrapper, proxy, or unexpected override can change behaviour in ways that are hard to reason about during review.
That matters in security-sensitive code because the runtime target can affect validation, permission checks, serialization behaviour, logging, and other control points. If a security decision is made before dispatch, or if an attacker can influence which object is passed into a sensitive call path, the resulting behaviour may diverge from what the developer intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-2 — Separation of System and User Functionality | Dynamic dispatch separates abstract call sites from concrete runtime behavior. |
| SI-10 — Information Input Validation | Runtime-selected method bodies still need trusted inputs before dispatch-dependent processing. | |
| Recommendation — Isolate security-critical logic from pluggable runtime behavior where call targets vary. Validate inputs before invoking dispatch-driven processing paths. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Dynamic dispatch is a core code-structure concern that affects predictability and control flow. |
| Recommendation — Review polymorphic call paths for hidden security assumptions and unsafe overrides. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Safe use of dynamic dispatch belongs in secure application design and code review practices. |
| Recommendation — Inspect object-oriented call paths for unsafe extension points and unintended behavior changes. | ||
Related resources from NHI Mgmt Group
- Why does a highly dynamic Active Directory environment increase security risk for emergency dispatch operations?
- What is the difference between safe dynamic dispatch and exploitable reflection in Ruby web applications?
- What is the difference between static and dynamic credentials?
- How do I migrate from static credentials to dynamic credentials?