近々本格的にコーディングを開始していく。
それにあたって、安全なコードとは何かを書き留めておこうと考えた。
ハードコートされた秘密情報の使用
ハードコートされたAPIキーやパスワード、その他の機密情報をコード内に埋め込むことは非常に危険なため、たとえ個人学習の範囲でもやってはいけない。
これらが含まれたリポジトリが公開された場合やコードが漏洩した場合、悪用されてしまうリスクがある。
悪い例：APIパスワードをコード内に直接記述する、機密情報をバージョン管理システムに含める。
被害：データの不正アクセス、管理者権限アカウントの乗っ取りでセキュリティを破壊される。
不適切なインプットバリデーション
ユーザー入力を適切に検証しないと、SQLインジェクションやXSS（クロスサイトスクリプティング）攻撃のリスクが高まる。
信頼できない入力をそのまま処理することは、アプリケーションのセキュリティを脅かしかねない。
悪い例：ユーザー入力を検証せずに直接データベースクエリを使用する、エスケープ処理を行わずにHTMLやJavaScriptのコンテンツとして出力する。
被害：攻撃者がデータベースクエリを操作してデータの漏洩やデータベースを破壊される、悪意あるスクリプトがユーザーのブラウザで実行され、セッションハイジャックやフィッシング詐欺が発生する。
セッションIDの露出
セッションIDは機密情報であり、第三者に漏れるとセッションハイジャックが発生しかねないため、セッションIDをURLに含めることや不適切な管理は避ける。
悪い例：セッションIDをURLに含める、管理を適切に行わずにセッションタイムアウトを設定しない。
被害：セッションIDが盗まれて正当なユーザーとしてシステムに不正アクセスされる、ユーザーのセッションが乗っ取られて不正な操作やデータ改ざんが行われる。
不十分なエラーハンドリング
詳細なエラーメッセージは攻撃者にシステムの内部構造を知らせる手がかりになる可能性があるため、適切にエラーハンドリングを行わないと攻撃の対象になりかねない。
悪い例：詳細なエラーメッセージをユーザー（ブラウザ）に表示する、スタックトレースやデバック情報を公開する、SNSでエラー文を公開して解決をしようとする。
被害：詳細なエラーメッセージからシステムの脆弱性が露見して利用される、エラーメッセージを利用して攻撃者がシステムを調査して攻撃を仕掛けやすくさせてしまう。
HTTPSの未使用
データ通信を暗号化しないと、第三者による盗聴や改ざんのリスクが高まる。これは通信セキュリティの信頼性を大きく損なう行為となる。
悪い例：HTTPを使用して機密データを送信する/させる、HTTPSを適切に設定せずにセキュリティ証明書の管理を怠る。
被害：HTTPを使用することで通信系を上でデータを盗聴される、攻撃者が通信データを改ざんしてユーザーに偽の情報を送り込まれる。
アップデートのパッチ適用を怠る
使用しているライブラリやフレームワーク、ソフトウェアの脆弱性を放置すると、既知の脆弱性を悪用されるリスクが高まるため、定期的なアップデートとパッチ適用は必須となる。
X（Twitter）の公式アカウントをフォローしたり英文ドキュメントにも目を通しておくべき。
悪い例：ライブラリやフレームワークを長時間アップデートしない、セキュリティパッチの適用を後回しにする。
被害：公開されている脆弱性情報を基に攻撃者がシステムに侵入してデータ漏洩やサービス停止が発生する、古いソフトウェアがマルウェアに感染してシステム全体が被害を受ける。
適切なアクセス制御の欠如
認証と認可を適切に実装しないと、不正なアクセスや権限のエスカレーションが発生する可能性がある。すべてのエンドポイントやリソースに対して適切な制御を行うことが重要。
悪い例：すべてのユーザーに同じ権限を与える、管理者機能や必要なリソースに対するアクセス制御を怠る。
被害：権限のないユーザーが機密情報にアクセスして情報漏洩が発生する、権限の低いユーザーが高い権限を不正に取得して重要な操作を実行する。
まとめ
Webセキュリティの基本的なガイドラインを守らないことは、重大なセキュリティインシデントが発生するリスクが高まる。
これにより、経済的な損失、社会的信用の失墜、法的責任が生じることもある。
Webアプリケーション開発においては、セキュリティ対策を鉄製して潜在的なリスクを最小限に抑えることが必要不可欠だ。
