Cybersecurity glossary
What is LDAP Injection?
Learn what LDAP injection is, how filter metacharacters alter directory searches, how authentication bypass works, and how to prevent unsafe LDAP query construction.
Definition
LDAP Injection is a vulnerability in which untrusted input is incorporated into an LDAP search filter or distinguished name so that attackers can alter query logic—often bypassing authentication or reading unauthorized directory attributes—using LDAP metacharacters rather than SQL syntax.
Why LDAP injection matters
Identity features often treat the corporate directory as a trusted oracle: look up a user, check a group, bind with a password. When those lookups are built by string concatenation, attackers do not need SQL—they need LDAP filter grammar. LDAP Injection turns a username field into a logic bomb against Active Directory, OpenLDAP, or any LDAP-backed IdP.
The impact is frequently authentication bypass or bulk disclosure of employee attributes. Because directory data underpins SSO and entitlements, a single filter bug can unlock far more than one application account.
How LDAP injection works
App builds an LDAP filter
User input is concatenated into a search filter or DN used for bind, lookup, or group checks.
Attacker inserts filter metacharacters
Characters such as * ( ) \ or NUL close clauses early and open always-true OR/AND branches.
Directory evaluates attacker logic
The LDAP server returns unintended entries or succeeds a search the developer assumed was narrow.
Auth or data impact follows
Login bypass, unauthorized attribute reads, or enumeration of users and groups.
Patterns to recognize
Filter clause breakout
Payloads close a (uid=…) clause and inject OR conditions that match any account.
Wildcard expansion
Injected * turns exact matches into broad searches that leak directory content.
Authentication bypass
Always-true filters make password checks irrelevant when the app trusts search results.
DN encoding abuse
Unescaped commas and equals in distinguished names redirect which object is resolved.
Prevention that works
| Control | Notes |
|---|---|
| Escape filters correctly | Encode *, (, ), \, and NUL per RFC 4515 before embedding in filters |
| Escape DNs separately | DN encoding rules differ from filter escaping—use the right encoder |
| Prefer safe LDAP APIs | Use libraries that parameterize or auto-escape filter arguments |
| Strict allowlists | Limit usernames/emails to short alphanumeric patterns when feasible |
| Least-privilege binds | Application LDAP accounts should only search required OUs and attributes |
| Separate auth from search | Prefer bind-as-user authentication over inventing password filters in search strings |
- Inventory every LDAP filter and DN built from request or stored user input.
- Replace string concatenation with escaping helpers or parameterized LDAP APIs.
- Add tests that inject *, (, ), \, and classic always-true filter payloads.
- Confirm login flows bind as the user rather than trusting a crafted search result.
- Restrict the service account’s search base and attribute list in the directory.
- Log anomalous directory searches that return unexpectedly large result sets.
- Review employee/directory UI search features—they often share the same filter builder.
- Treat confirmed LDAP injection as high severity until directory exposure is scoped.
The practical takeaway
LDAP injection happens when untrusted input reshapes a directory filter or DN. It is not SQL injection: escape LDAP metacharacters, use safe APIs, and never invent authentication as a home-grown search filter.
If a feature looks up people in a corporate directory, assume every username will try to close a parenthesis until your tests prove otherwise.
Related security terms
LDAP
The directory protocol whose search filters and DNs are the injection target.
SQL Injection (SQLi)
A related injection class against SQL—similar root cause, different language.
XPath Injection
Injection into XML path queries, often compared alongside LDAP filter abuse.
NoSQL Injection
Another query-logic injection family with operator and type confusion patterns.
Frequently asked questions
What is LDAP injection in simple terms?
The application builds an LDAP search using user input. An attacker adds filter punctuation such as *, (, ), or \ so the directory returns more (or different) entries than intended—sometimes enough to log in without a valid password.
Is LDAP injection the same as SQL injection?
No. Both rewrite query logic from unsafe concatenation, but LDAP uses filter grammar (RFC 4515), not SQL. Blocking SQL quotes does not stop LDAP metacharacters.
Which characters are dangerous in LDAP filters?
Common filter metacharacters include * ( ) \ and NUL. Distorted DNs also abuse , = + < > ; " and leading/trailing spaces depending on encoding rules.
Where do these bugs commonly appear?
Login against a corporate directory, employee/search directories, group membership lookups, and any feature that embeds username or email into an LDAP filter string.
What does a classic authentication bypass look like?
A filter like (&(uid=USER)(userPassword=PASS)) can be broken with USER=*)(uid=*))(|(uid=* so the filter becomes always-true for some directory trees and returns a matching entry.
What is the primary defense?
Never concatenate raw input into filters or DNs. Escape per RFC 4515 / DN encoding rules, prefer parameterized LDAP APIs, and allowlist short alphanumeric identities when possible.
Can a WAF fully stop LDAP injection?
Signatures may catch obvious payloads, but encoding tricks and application-specific filters bypass WAFs. Fix query construction at the source.
References
Explore authoritative guidance and frameworks related to ldap injection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.