セキュリティとプライバシー

フォームを作成するときに、ユーザーデータを処理します。一番の懸念は、ユーザーデータのプライバシーを確保し、安全に転送することです。 何ができるか見てみましょう。

最初のステップとして、リクエストするデータをできるだけ少なくします。不要なデータは要求せず、リクエストされたデータがすべて必要かどうかを必ず確認してください。データが少ないほど、リスク、コスト、責任が軽減されます。 また、フォーム内のフィールド数を減らすと、入力が複雑でなくなり、入力が簡単になり、放棄率の低減にもつながります。

常に HTTPS を使用します(特にフォームが含まれるページ)。HTTPS では、サーバーから送信されるデータとサーバーに戻るときにデータが暗号化されます。

たとえば、カフェで公衆 Wi-Fi を使用しているとします。 e コマースサイトを開き、クレジット カード情報を入力して何かを購入します。ウェブサイトで HTTP を使用している場合、同じ公衆 Wi-Fi を使用するすべての人(そのスキルを持つ人)がクレジット カード情報を読み取る可能性があります。ウェブサイトで HTTPS を使用している場合、データは暗号化され、誰からもアクセスできないよう保護されます。

サイトで、HTTP リクエストを HTTPS にリダイレクトすることも必要です。詳しくは、すべてのトラフィックを HTTPS にリダイレクトする方法をご覧ください。

ユーザーのデータのプライバシーを保護する

最初のモジュールでは、データを転送する 2 つの方法(GET リクエストと POST リクエスト)について学習しました。

GET リクエストでは、フォームデータがリクエスト URL にクエリ文字列として含まれます。GET リクエストを使用するフォームを送信すると、ブラウザはフォームデータを含むリクエスト URL を閲覧履歴に追加します。検索フォームなど、過去のフォーム送信内容を確認する場合に便利です。ただし、機密データが送信され、ブラウザの履歴やローカル ネットワークにアクセスできるすべてのユーザーがこの情報を見ることができる場合は、まったく問題ありません。

個人情報や機密情報を送信する可能性があるすべてのフォームで POST リクエストを使用します。このようにして、データを処理するバックエンド スクリプトからのみデータを参照できます。

個人データをブラウザに直接保存して処理できますか? 個人データをブラウザに保存するために、クライアント ストレージ(localStorage など)を使用できます。プライバシーに関しては、これは理想的とは言えません。 繰り返しになりますが、この情報は、ブラウザにアクセスできるすべてのユーザーが読むことができます。個人データには暗号化された値のみを保存してください。

ユーザーが安全に登録とログインできるようにする

ユーザー アカウントの認証は、プライバシーとセキュリティの点で複雑な問題です。独自の安全な認証システムを構築するのではなく、サードパーティの ID プロバイダを使用することをおすすめします。

アカウント認証とパスワード管理のベスト プラクティスについて学習する。

ユーザーが個人データにアクセスできるようにする

カリフォルニア州の CCPA、インドの PDPA など、多くの地域にはデータ保護とプライバシーに関する法律と規制があります。欧州連合(EU)で利用できるウェブサイトは、サイトが EU 内にない場合でも、一般データ保護規則(GDPR)に準拠する必要があります。

GDPR は、EU 在住のユーザーからの個人情報の収集と処理に関するガイドラインを定めています。個人データの処理には同意が必要です。ユーザーはいつでも保存した個人情報をリクエストでき、デベロッパーはデータ漏洩を正式に発表する必要があります。これは、ユーザーのプライバシーが尊重されるため、ユーザーにとっては望ましいことです。GDPR の詳細を確認する。

個人データの取り扱いについて、ユーザーに周知してください。 透明性は信頼の鍵となります。ユーザーのために保存したすべてのデータに、ユーザーはいつでもアクセス、変更、削除できる必要があります。

ユーザーが個人データを更新できるようにする

パスワード、メールアドレス、ユーザー名などの個人データをユーザーが簡単に更新できるようにします。保存されている個人データの変更についてユーザーに通知し、ユーザーが変更を取り消せるようにします。たとえば、ユーザーがメールアドレスを変更したら、以前のメールアドレスと新しいメールアドレスにメールを送信できます。

ユーザーがアカウント(すべての関連データを含む)を簡単に削除できるようにします。また、該当する場合はデータをダウンロードできるようにします。一部の地域では、アカウントの削除は法的要件になっています。

サイトで個人情報を表示または変更するために、現在のパスワードの再入力など、追加の認証手順を要求する。

詳細については、ウェブ アプリケーションのプライバシーに関する推奨事項をご覧ください。

すべてのデータが良好な状態にあることを確認する

前のモジュールで、フロントエンドでの検証について学習しました。フロントエンドの検証は重要ですが、ユーザーが無効なデータを送信できる可能性もあります。次のステップでは、データをデータベースに保存する前に、バックエンドでもデータを検証する必要があります。これにより、無効なデータがデータベースに保存されなくなります。

検証は、データ形式が有効であることを確認するのに役立ちますが、ユーザーが入力したデータを信頼すべきではありません。データを安全に出力するにはどうすればよいでしょうか。クロスサイト スクリプティング(XSS)を防止し、すべてのデータが HTML に安全に含まれるようにするには、出力前にデータをサニタイズする必要があります。

出力前のデータのサニタイズについて詳細を確認し、可能であれば Sanitizer API を使用します。

すべての投稿が実際の人物によるものであることを確認する

データを保護できるよう、bot によるスパム送信を防ぐさまざまなオプションがあります。

1 つ目の方法は、reCAPTCHA などのサービスを使用して、実在の人物と bot を区別することです。そのためには、ページに JavaScript スニペットを追加し、[送信] ボタンに属性を追加する必要があります。

reCAPTCHA は、ユーザーが人間かどうかを判断するためにさまざまなチェックを行います。たとえば、画像の識別を求められることがあります。 bot などの自動ソフトウェアでは、このような課題を解決できず、フォームを送信することもできません。

ハニーポット

もう一つの選択肢は、いわゆる「ハニーポット」(視覚的に隠されたフォーム フィールド)を使用することです。人間にはハニーポットのフィールドは表示されませんが、ボットはそこに入力します。バックエンドでは、処理スクリプトがフィールドの入力が完了したかどうかを確認できます。もしそうならば、送信は bot からのものである可能性が高いため、無視してかまいません。

また、スパム対策に役立つ Akismet などのサービスもあります。Akismet フィルタは、参加しているすべてのサイトで収集されたスパムに関する情報を組み合わせ、それらのスパムルールを使用して今後のスパムをブロックします。Akismet はユーザーに対して透過的で、ほとんどのスパムを検出します。

理解度をチェックする

セキュリティとプライバシーに関する知識をテストする

フォームを使用して個人データを転送するのに推奨される方法は何ですか。

運母のハト。
HTTPS
GET リクエスト。
POST リクエスト。

スパムを防ぐ方法

ベジタリアン用のフォームのみを提供する。
Honeypot フォーム フィールド。
スパム サービス。
キャプチャ

リソース