---
{
  "title": "LDAP injection",
  "summary": "LDAP injection occurs when untrusted values change a directory query or distinguished name.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: LDAP Injection Prevention",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

LDAP injection occurs when untrusted values change a directory query or distinguished name. LDAP search filters and distinguished names have different escaping requirements. A safe design treats caller input as a value in a fixed operation and limits what the application's directory identity may retrieve.

## A practical example

An employee directory searches for a submitted surname. The implementation encodes it for an LDAP filter rather than assembling unrestricted filter syntax. The bind account cannot read unrelated sensitive directory attributes.

## What to check

Use maintained LDAP-specific encoding or frameworks, distinguish filter encoding from distinguished-name encoding, and constrain returned attributes. Test special characters in the precise context where input is inserted.

## A common pitfall

SQL escaping is not LDAP escaping. Similar-looking query strings follow different grammars, and reusing an unrelated encoder can leave control characters active.

## Think it through

Why do a search filter and a distinguished name need different handling?

**Answer:** They use different syntax rules, so their reserved characters and correct escaping are not interchangeable.

## Directory syntax has more than one context

A fictional staff directory allows searching for a surname. The application constructs an LDAP search filter, receives matching entries, and displays a restricted set of attributes. The user should control the surname value, not the filter's structure or the search base. A review follows that value to the directory operation rather than stopping at the web form.

Distinguished names and search filters use different syntax. An escaping function intended for one is not automatically suitable for the other. Choose a maintained API that provides the appropriate construction or encoding behavior and confirm its documented contract. Reusing a generic 'escape special characters' helper obscures which parser it protects.

Directory permissions affect the consequence of a defect. A search-only application should not bind with an account able to modify groups or read every sensitive attribute. Limit the search base, returned attributes, and service-account authority to what the feature needs. These restrictions complement safe filter construction rather than compensating for an unsafe query.

## Explain the intended directory operation

For a local exercise, describe a surname search against dummy staff records. Mark the fixed search base, fixed filter structure, supplied surname, and permitted returned attributes. Include an ordinary name containing punctuation and an unsupported request to search another organizational branch. State which input rules and directory permissions apply.

Investigate unexpected broad results carefully. They may come from an injection flaw, an overly broad search rule, or legitimate directory data. A useful finding shows the specific interpretation boundary and the resulting unauthorized behavior without exporting unrelated personnel records. Retesting should cover the shared directory helper and every application route that uses it.

## Related concepts

- [[ldap]]
- [[injection]]
- [[input-validation]]