開発者は、スプリントの締め切りや機能リクエストの重圧の中で日々を過ごしています。パフォーマンスのチューニングやUIのブラッシュアップは称賛を浴びますが、セキュリティは通常バックログに置かれ、静かに自分の番を待っています。その「待ち」は間違いです。自動化されたボットが24時間体制でインターネットをスキャンし、漏洩したキー、インジェクションポイント、脆弱な認証を探索しています。データ侵害はテックニュースにおいて日常的な出来事のようになっていますが、責任を負うチームにとって、その事後処理は過酷なものです。幸いなことに、セキュアなコードを書くのに暗号学の博士号は必要ありません。日々のワークフローにいくつかの強力な習慣を組み込むだけでよいのです。ここに、ユーザーとシステムを真に保護するための5つのプラクティスを紹介します。

認証を保護する

多くのチームが、独自のログインシステムを急造したいという誘惑に駆られます。usersテーブル、passwordカラム、JWTジェネレーター。セッション管理、トークンローテーション、ブルートフォース対策、そして安全なパスワードリセットまで自前で管理しなければならないと気づくまでは、単純な作業に思えます。ほとんどのチームは、これをゼロから構築するのをやめるべきです。OAuth 2.0やOpenID Connectを通じて、確立されたアイデンティティプロバイダーに認証を委ねることで、コードベースからリスクのカテゴリー全体を排除できます。何千人ものエンジニアによって実戦投入され、広範なセキュリティコミュニティによってレビューされてきたプロトコルをそのまま利用できるのです。

とはいえ、もしパスワードを自分で扱う必要がある場合は、それらを慎重に扱ってください。すべてのパスワードをbcryptまたはArgon2を使用してハッシュ化してください。これらのアルゴリズムは、意図的に低速に設計されています。その遅さによって、データベースを盗み出し、オフラインでパスワードを解析しようとする攻撃者の動きを抑制できます。パスワードをプレーンテキストのまま放置してはいけません。ログにも、クラッシュレポートにも、どこにも残さないでください。

多要素認証（MFA）は、もはやオプションではありません。パスワードは漏洩します。フィッシングは成功します。TOTPアプリであれハードウェアキーであれ、第2の要素を導入することで、アカウント乗っ取りの発生率を劇的に下げることができます。

セッショントークンやJWTを発行する場合は、HttpOnlyおよびSecure属性を持つCookie内に保存してください。HttpOnlyフラグはJavaScriptによるCookieの読み取りを阻止し、多くのクロスサイトスクリプティング（XSS）攻撃を無効化します。Secureフラグは、ブラウザがHTTPS経由でのみCookieを送信することを保証します。JWTをlocalStorageに保存しないでください。便利に思えますが、サイトにXSSの脆弱性が一つでもあると、攻撃者はユーザーのトークンに即座にアクセスできてしまいます。

OWASP Top 10を基準として扱う

OWASP Top 10は、理論的な試験のシラバスではありません。それは、Webアプリケーションが実際に侵害される最も一般的な手法のカタログです。それを無視することは、自分の反射神経を過信して交通標識を無視するようなものです。

SQLインジェクションは、最初に記録されてから数十年経った今でも、本番環境のデータベースを脅かし続けています。対策は単純ですが、規律が必要です。ユーザー入力をクエリ文字列に結合してはいけません。パラメータ化クエリを使用するか、エスケープ処理を自動で行ってくれるPrismaのようなORMを使用してください。データベースドライバーがコードとデータを分離するため、悪意のある入力によってクエリのロジックが書き換えられることはありません。

クロスサイトスクリプティング（XSS）は、フィルタリングされていないユーザー入力を餌に発生します。アプリケーションがユーザーの送信内容をそのままレンダリングする場合は、まずサニタイズしてください。モダンなフレームワークは多くの場合、デフォルトで出力をエスケープしますが、カスタムコンポーネントやdangerouslySetInnerHTMLスタイルのAPIは、それらのガードレールをバイパスしてしまう可能性があります。何を信頼するかを明確にしてください。

クロスサイトリクエストフォージェリ（CSRF）は、ブラウザを欺いて意図しないアクションを実行させます。フォームに埋め込まれたanti-CSRFトークンを使用してこれを軽減し、CookieにSameSite属性を設定してください。SameSite=LaxまたはStrictを指定することで、クロスオリジンリクエストの際にブラウザにCookieの送信を控えるよう指示でき、ほとんどのCSRFを完全に阻止できます。

最小権限の原則を適用する

すべてのユーザーに管理者権限が必要なわけではありません。すべてのマイクロサービスにデータベースへのrootアクセスが必要なわけでもありません。最小権限の原則とは、特定のタスクに必要な分だけのアクセス権を付与し、それ以上は与えないことを意味します。

まずはアプリケーションのデータベースユーザーから始めましょう。バックエンドが単に行の読み書きのみを必要とする場合は、テーブルの削除（drop）、スキーマの変更（alter）、または新しいデータベースの作成といった権限を削除してください。攻撃者がアプリケーションを侵害した場合、それらの制限された権限が防壁となります。データを盗まれることはあっても、コマンド一つでインフラ全体を消去されることは防げます。

同じ考え方をクラウド環境にも適用してください。AWS IAMロール、Google Cloudのサービスアカウント、AzureのマネージドIDは、個々の操作に限定してスコープを設定すべきです。静的アセットのデプロイのみを行うCI/CDパイプラインに、高価なコンピューティングクラスターを起動する権限は必要ありません。これらをレビューしてください。