DeepL API の axios 脆弱性を回避する安全な実装
こんにちは、今回は DeepL API を導入する際に直面した axios の脆弱性問題と、それに対する実用的な回避策について解説します。
この問題は私が個人開発で翻訳機能を実装した時に直面した問題でした。
課題
DeepL API の npm パッケージが抱える axios 脆弱性
DeepL API を簡単に使えるようにするための非公式 npm パッケージ deepl を導入したところ、以下のような axios の脆弱性 が npm audit により検出されました：
報告された脆弱性
- CSRF（クロスサイトリクエストフォージェリ）
- SSRF（サーバーサイドリクエストフォージェリ）
- 認証情報の漏洩の可能性
なぜ問題か？
これらの脆弱性が存在するライブラリを利用し続けると、以下のようなリスクがあります：
- サーバー上の他サービスや認証情報への不正アクセス
- エンドユーザーのセッションハイジャック
- 開発者が意図しない外部通信
解決策：axios を使用せず、fetch による直接実装
DeepL の REST API は非常にシンプルな構造を持っているため、fetch を使って直接リクエストを送る実装が可能です。
実装例（Node.js / Next.js）
const response = await fetch("https://api-free.deepl.com/v2/translate", {
method: "POST",
headers: {
Authorization: `DeepL-Auth-Key ${process.env.DEEPL_AUTH_KEY}`,
"Content-Type": "application/x-www-form-urlencoded",
},
body: new URLSearchParams({
text: "翻訳したいテキスト",
target_lang: "EN-US",
}),
});
const data = await response.json();
console.log(data.translations[0].text);
メリット
- axios のような依存関係を追加せずに済む
- npm audit で脆弱性を報告されない
- fetch はブラウザ・Node.js 双方で利用可能
適用範囲と補足
この回避策は以下のようなプロジェクトに特に有効です：
- 外部APIを少数利用する小規模〜中規模Webアプリ
- セキュリティレビューを重視するB2B/B2Cアプリ
- 自社内にセキュリティチェックが入るプロダクト開発
✍️ 補足：2025年4月時点では、
deepl-nodeという公式のNode SDKも提供されていますが、fetchでの軽量な実装も十分に安全かつ柔軟に運用できます。
まとめ
axios は非常に便利な HTTP クライアントですが、第三者製パッケージに依存することで不要な脆弱性を取り込むリスクも存在します。
DeepL API を安全に運用するためには、fetch によるシンプルな直接実装が現時点での最善策の一つです。
セキュリティを意識した API 実装に取り組む方の参考になれば幸いです。
ご意見やフィードバックがあれば、ぜひコメントで教えてください！