JSONからSQLへの変換時の文字列エスケープ

SQL安全のための文字列エスケープ

JSON文字列値をSQLリテラルに変換する際、構文エラーとSQLインジェクション脆弱性を防ぐために適切なエスケープが不可欠です。主な懸念事項は、SQLで文字列リテラルを区切るシングルクォートの処理です。

問題

{
  "name": "O'Brien",
  "bio": "She said \"hello\"",
  "path": "C:\\Users\\data"
}

エスケープなしでは、生成されるSQLが壊れます：

-- 壊れる：シングルクォートが文字列を早期に終了させる
INSERT INTO users (name) VALUES ('O'Brien');

正しいエスケープ

INSERT INTO users (name, bio, path) VALUES
  ('O''Brien', 'She said "hello"', 'C:\Users\data');

データベース別のエスケープルール

文字	PostgreSQL	MySQL	SQL Server
シングルクォート '	''	'' または \'	''
バックスラッシュ \	リテラル	\\\\（NO_BACKSLASH_ESCAPESがオフの場合）	リテラル
NULLバイト	非対応	\0	非対応

SQLインジェクション防止

エスケープはSQLインジェクションに対する第一の防御線です。この悪意のあるJSONを考えてみましょう：

{ "name": "'; DROP TABLE users; --" }

適切なエスケープにより：

INSERT INTO users (name) VALUES ('''; DROP TABLE users; --');
-- シングルクォートがエスケープされ、文字列全体がデータとして扱われる

Unicode処理

JSONは\uXXXXエスケープシーケンスでUnicodeをネイティブにサポートします。ほとんどの最新データベース（UTF-8エンコーディング）は、文字列リテラル内のUnicode文字を直接受け入れます：

INSERT INTO products (name) VALUES ('Cafe Latte');

ベストプラクティス：パラメータ化クエリ

コンバーターは便利のためにエスケープされたSQLを生成しますが、本番アプリケーションではインジェクションを完全に回避するためにパラメータ化クエリ（$1、?、:name）を使用すべきです。生成されたSQLは一回限りのインポート、シード、デバッグに最適です。