LDAP injection occurs when an app builds an LDAP query from untrusted input without escaping it, letting an attacker modify the query's logic. LDAP queries directory services (e.g. Active Directory) - often for login and user lookups - so injecting LDAP filter syntax enables authentication bypass and directory enumeration (listing users, groups, attributes, sometimes password-related fields). It hides in login forms and search features that query a directory. The fix: never concatenate input into filters - use your platform's LDAP escaping functions / safe filter APIs so metacharacters are treated as data, plus input validation and least-privilege directory accounts. Same principle as SQL injection: safe construction, not filtering. Detail below; part of every web app and AD assessment.
// 01 How LDAP injection works
LDAP (Lightweight Directory Access Protocol) is how applications query directory services - most commonly Active Directory - to authenticate users and look up their information. An app builds an LDAP filter like (&(uid=<input>)(password=<input>)) to find a matching user. The vulnerability, exactly like SQL injection, appears when the app concatenates user input into that filter without escaping. LDAP filters have their own metacharacters and operators - * (wildcard), (, ), &, | - and an attacker who supplies them can change what the query matches. For instance, a wildcard or an always-true condition can turn “find this user with this password” into “find any user,” or broaden a search to return everything. The root cause is the familiar one: user input crossing from data into query syntax - but here the query runs against your identity directory, which is what makes it dangerous.
// 02 What an attacker gains
Two impacts dominate. Authentication bypass: by injecting LDAP filter syntax into a login, an attacker crafts a query that matches without valid credentials - logging in as a user, or defeating the check entirely. Information disclosure / directory enumeration: by manipulating a search query (e.g. a user directory or address book), an attacker broadens what it returns to enumerate the directory - listing users, groups and their attributes, and extracting sensitive data like email addresses, roles, and in some cases password-related attributes. Because directory services underpin identity across the whole organisation, LDAP injection that exposes directory contents or bypasses authentication can be a significant breach - and it's frequently a stepping stone to wider access, feeding the reconnaissance an attacker uses for Active Directory attacks and Kerberoasting.
// 03 Where it hides
Login forms
Any login that authenticates against a directory - the classic bypass target.
User / address search
People-finder and address-book features that query the directory - the enumeration target.
SSO & lookups
Apps integrated with AD/LDAP for single sign-on, user lookups or authorisation.
Hidden checks
Less obvious spots like group-membership checks that build a filter from input.
The vulnerability lives in how the filter is built, so it can hide in any feature that lets a user influence a directory query. A tester probes every input that could reach an LDAP query, not just the obvious login.
// 04 How to test & prevent
Testing: at each candidate input, inject LDAP metacharacters - a lone ) to trigger a filter error, a * wildcard to broaden matches, and always-true conditions - and observe whether the query's behaviour changes: a login that succeeds without a password, a search that suddenly returns far more results, or an LDAP error revealing the filter. It's manual, syntax-aware work like other injection testing. Prevention: never build filters through unescaped string concatenation. Use the LDAP escaping functions your platform/library provides to safely encode any user value in a filter, so metacharacters are treated as literal data; prefer library APIs that build filters safely over hand-assembled strings; apply input validation against expected formats; and use least-privilege directory accounts so a successful injection is limited in what it can read. As with every injection class, safe query construction is the reliable fix - manual character filtering is error-prone. It's checked in our web app and Active Directory assessments, per our methodology.
// 05 Frequently asked questions
What is LDAP injection?
A vulnerability where an app builds an LDAP query from untrusted input without properly escaping it, letting an attacker modify the query's logic. LDAP queries directory services like Active Directory, often for authentication and user lookups. Injecting LDAP metacharacters and operators changes what the query matches, so it can lead to authentication bypass and unauthorised access to directory data.
What can an attacker do with it?
Authentication bypass (craft a query that matches without valid credentials) and information disclosure (manipulate a search to enumerate the directory - users, groups, attributes - and extract emails, roles, sometimes password-related attributes). Because directory services underpin identity, LDAP injection exposing directory contents or bypassing auth can be a significant breach, and often a stepping stone to wider access.
Where does it appear?
Anywhere an app builds an LDAP query from user input - most commonly login forms that authenticate against a directory, and user or address-book search features. Apps integrated with Active Directory or another LDAP directory for SSO, lookups or authorisation are typical. It can hide in any feature letting a user influence a directory query, including group-membership checks. A tester probes every input that could reach an LDAP query.
How do you prevent it?
Never build filters through unescaped concatenation. Use your platform's LDAP escaping functions to encode any user value in a filter so metacharacters are literal data; prefer safe filter-building APIs over hand-assembled strings; apply strict input validation; and use least-privilege directory accounts. As with other injection classes, safe query construction is the reliable fix; manual character filtering is error-prone.
// 06 Related reading
- SQL injection and command injection — the injection family.
- Active Directory attack paths and Kerberoasting — where directory data leads.
- Active Directory assessment and web app testing.