feat(langchain): enhance SQL security with validation, parameterization and injection protection

[christian-bromann]

This PR introduces comprehensive security improvements to the SqlDatabase class to protect against SQL injection attacks and other security vulnerabilities.

🚀 Key Features

Security Enhancements:

• SQL Injection Protection: Detects and blocks 20+ dangerous SQL patterns including:
  • Multiple statement execution (; DROP TABLE)
  • OR-based injection (OR 1=1)
  • Comment-based injection (--, /* */)
  • Union-based injection (UNION SELECT)
  • Command execution attempts (xp_cmdshell, sp_executesql)
• Parameterized Queries: New overloaded run() method supports safer parameter binding
• Statement Validation: Configurable allowed SQL statements (default includes all for backward compatibility)
• Query Length Limits: Prevents DoS attacks with configurable maximum query length (default: 10,000 chars)
• Multiple Statement Prevention: Blocks stacked queries and command chaining

Configuration Options:

const db = await SqlDatabase.fromDataSourceParams({
  appDataSource: dataSource,
  allowedStatements: ["SELECT"],           // Restrict to read-only
  enableSqlValidation: true,               // Enable security validation
  maxQueryLength: 5000,                    // Custom query length limit
});

🔧 Usage Examples

Secure parameterized queries (recommended):

// ✅ Safe - uses parameter binding
const result = await db.run(
  "SELECT * FROM users WHERE age > ? AND name = ?", 
  [18, "John"]
);

Traditional string queries (with validation):

// ⚠️ Validated but less secure
const result = await db.run("SELECT * FROM users WHERE age > 18");

🔄 Backward Compatibility

All existing functionality remains unchanged. Security features are enabled by default but can be configured or disabled for compatibility with legacy applications.

I would consider this non-breaking, however it is technically breaking as security defaults are stricter.

🛡️ Security Impact

This addresses potential SQL injection vulnerabilities while maintaining flexibility for legitimate use cases through configurable security settings.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langchainjs-docs	✅ Ready (Inspect)	Visit Preview		Jun 17, 2025 7:15am

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
langchainjs-api-refs	⬜️ Ignored (Inspect)			Jun 17, 2025 7:15am

[hntrl]

On the surface I think it's a good change to codify our security best practices rather than saying "just do this," but I wonder if there's a better form factor than baking this into the sql abstraction directly. That way we can reuse it and we're not forcing people to use our opinionated way of interfacing with their data.

Something to the tune of:

// hypothetical
const validator = new SqlValidator({
  allowedStatements: ["SELECT"],
  enableSqlValidation: true,
  maxQueryLength: 10000
});

const db = await SqlDatabase.fromDataSourceParams({
  appDataSource: datasource
});

await model.pipe(validator).pipe(db).invoke(...);

@christian-bromann thoughts?

[christian-bromann]

I can definitely see the appeal of extracting the validation logic into a separate SqlValidator class—especially for use cases where modularity or reuse across different adapters is valuable. From a design perspective, that separation could make things more composable and clearer for advanced users who want full control.

That said, from my point of view, there's also something reassuring about having strong validation and protection built directly into the SqlDatabase implementation. A few reasons why I personally lean in that direction:

• Security-first defaults: I’ve found that when it comes to security, it’s generally helpful to have safe behavior enabled by default—especially in libraries like LangChain where users might not expect to configure every detail themselves. Requiring an extra step to get that protection might increase the risk of someone unintentionally skipping it.
• Lower cognitive overhead for most users: For many use cases, it seems beneficial if users don’t have to learn about or manually wire in an additional primitive like a validator class. If the goal is to make it easy to do the secure thing, having it integrated into SqlDatabase helps reduce friction.
• Still configurable: I really like that this PR keeps things flexible through the allowedStatements and enableValidation options. So while there are strong defaults, users who need something different still have an escape hatch.

Of course, happy to follow whatever direction the team feels is best here—whether that's evolving this into a separate component or keeping the validation built-in.

[hntrl]

Maybe there's a 'best of both' worlds approach to this where we have a default validator instance inside of SqlDatabase. That way someone can break it out if they want to, but it still lets them bring some kind of validation if they choose to have their own way of issuing queries:

class SqlDatabase {
  // the default
  protected validator: SqlValidator | null = new SqlValidator({
    allowedStatements: ["SELECT"],
    enableSqlValidation: true,
    maxQueryLength: 10000
  });
}

// 1. I can either pipe to SqlDatabase that has the default validator
model.pipe(new SqlDatabase(...));

// 2. Use a custom validator in SqlDatabase
model.pipe(new SqlDatabase({
  validator: new SqlValidator(...),
  ...
}));

// 3. Or use SqlValidator before using my own database call
model.pipe(new SqlValidator(...)).pipe(dbRunnable);

I could also see it being useful in traces to have a distinct validation step.

Looking into this some more, I'm gathering that the straight to .pipe syntax for SqlDatabase isn't possible today (it isn't a runnable), but it might make for an interesting iteration for sql tooling (this code was last updated 2 years ago!). If we hoist SqlValidator into its own class as a runnable, then it's possible to retrofit SqlDatabase to use validation defaults and also lets us use sql validation in a chain.