今回は、ネットワークの基礎となる

• スループット
• レイテンシー
• IOPS

を紹介したいと思います。

インフラ構築をしているとよく出てくるキーワードですが、度々こんがらがってしまうため改めて学び直します。

お前ら何やねん

スループットとは

特定の時間にネットワークを実際に通過できるデータの平均量を指します。

つまり通信速度です。

5Gbps=5×1,000,000,000ビット/秒=5,000,000,000ビット/秒

1秒間に10億ビット通過できるんだ-と思いますが、ネットワーク内には様々なリソースがあるので、提供されるスペック通りの値が通過できるとは限りません。あくまで平均ね。

レイテンシーとは

リクエストを送信してから応答が返ってくるまでの遅延時間を指します。

ちょうわかりやすく言うと、「データの処理や通信がどれだけ迅速に行われるか」の指標のことです。

IOPSとは

ストレージやデータベースが1秒間に処理できる入出力操作の回数を指します。

IOPSはスループットとある程度、比例関係にあります。

• 小さいブロックサイズの場合、1回のIO操作で処理されるデータ量が少ないため、操作回数が多くなり、IOPSが増加する
• 大きなブロックサイズの場合、1回のIO操作で大量のデータを処理するため、IO操作回数が少なくなり、IOPSは減少しますが、スループットは向上する

3つの違いのまとめ

レイテンシー

• 嬉しい状態:低いほうが嬉しい
• 理由:
  レイテンシーが低い（つまり遅延時間が短い）ほど、システムがより速く応答し、ユーザーが操作を行った際の待ち時間が少なくなります。
  たとえば、Webページが速く表示されたり、データベースのクエリが迅速に実行されたりすることで、ユーザー体験が向上します。
• 例: ネットワークレイテンシーが低いと、Webサイトの応答が速くなります。

スループット

• 嬉しい状態: 高いほうが嬉しい
• 理由:
  スループットが高いほど、システムが短時間で多くのデータやリクエストを処理できることを意味します。
  特に、大量のデータを処理する場合や多くのユーザーが同時にアクセスするシステムにおいて、高いスループットはシステムの効率や全体のパフォーマンスを向上させます。
• 例: スループットが高いネットワークでは、1秒間に多くのデータを送受信でき、ダウンロードやストリーミングがスムーズに行えます。

IOPS 

• 嬉しい状態: 高いほうが嬉しい
• 理由:
  IOPSが高いほど、ストレージデバイスが1秒間に処理できる入出力操作の回数が多くなります。
  これは、特にデータベースやファイルシステムなど、頻繁にデータの読み書きが発生するシステムにとって重要です。
  高いIOPSは、より多くの入出力操作を短時間で処理できるため、パフォーマンスが向上します。
• 例: IOPSが高いSSDは、ディスクアクセスが多いアプリケーション（例えばデータベースクエリやログ書き込み）の性能を大幅に改善します。

この記事では、これらのプロトコルの基本、特にメソッド、ステータスコード、ヘッダー、クッキーという要素に焦点を当て、それらがどのようにWebの基盤となっているかを掘り下げます。

さらに、HTTPSがHTTPにセキュリティ層を追加する方法と、その重要性についても触れていこうと思いまっす

1. RESTful APIとは？
2. SPA（シングルページアプリケーション）とは？
3. RESTful APIとSPAの関係性
4. PHPとReactを使った例
   • PHPによるRESTful API
   • ReactによるSPA
5. セキュリティとパフォーマンスの考慮
   • セキュリティ
   • パフォーマンス

RESTful APIとは？

RESTful APIは、ウェブアプリケーションやウェブサービスで使われるプログラミングインターフェースです。
REST（Representational State Transfer）の原則に基づいて設計されており、ウェブ上のリソースへのアクセスや操作を統一的な方法で提供します。
リソースはURLで識別され、HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってアクセスされます。

[getpost id=”1672″ cat_name=”1″ date=”0″]

SPA（シングルページアプリケーション）とは？

SPAは、ユーザーがアプリケーションを操作する際にページの再読み込みをせずに、必要なデータのみをサーバーから非同期に取得し、動的にページの内容を更新するウェブアプリケーションの形式です。

これにより、従来のマルチページアプリケーションに比べてユーザーエクスペリエンスが向上します。

僕が所属しているチームでもページのリロードが嫌だというユーザーの使用感からSPAへの移行が少しづつ始まってきています。
世間的にもSPAは流行っていますよね。（流行っているから偉いというわけではない。知ることが大事

RESTful APIとSPAの関係性

SPAでは、ページの初回読み込み時にアプリケーションの全てのコード（HTML、CSS、JavaScript）がロードされます。

その後のユーザーの操作によってデータが必要になる場合、SPAはRESTful APIを通じてサーバーからデータを非同期に取得します。
このデータはJSONやXML形式で返され、JavaScriptを用いてクライアントサイドで処理され、ページの一部分だけが動的に更新されます。

このアーキテクチャにより、SPAはユーザーにスムーズで反応の良いインターフェイスを提供できます。

RESTful APIはこのプロセスの背後にあるデータ通信の基盤となります。

PHPとReactを使った例

ここでは、PHPで書かれた簡単なRESTful APIと、Reactを使ったSPAの例を示します。

PHPによるRESTful API

PHPで簡単なAPIエンドポイントを作成します。この例では、GETリクエストを受け取り、簡単なJSONデータを返します。

<?php 
    header('Content-Type: application/json');
    $response = ['message' => 'Hello, world!'];
    echo json_encode($response); 

    // Response
    //{"message": "Hello, world!"} ?>

このPHPスクリプトは、サーバーに配置してのようにアクセスするとJSONが返されます。

ReactによるSPA

Reactで簡単なSPAを作成し、上記のAPIからデータを取得して表示します。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function App() {
  const [message, setMessage] = useState('');

  useEffect(() => {
    axios.get('http://yourserver.com/index.php')
      .then(response => {
        setMessage(response.data.message);
      })
      .catch(error => console.error('There was an error!', error));
  }, []);

  return (
    <div>
      <button>{message}</button>
    </div>
  );
}

export default App;

SPA（シングルページアプリケーション）とRESTful APIを使用する際には、セキュリティとパフォーマンスの両方に配慮することが重要です。
以下では、これらの観点から基本的なガイドラインをいくつか紹介します。

セキュリティ

1. HTTPSを使用する
   データの暗号化を確実に行うため、APIとの通信には常にHTTPSを使用します。（当たり前です）
   これにより、中間者攻撃（MITM）のリスクを減らすことができます。
2. CORSポリシーを適切に設定する
   クロスオリジンリソースシェアリング（CORS）ポリシーを適切に設定し、信頼できるオリジンからのリクエストのみを許可します。
   不適切なCORS設定は、セキュリティリスクを招く可能性があります。
3. 認証と認可
   JWT（JSON Web Tokens）やOAuthなどの堅牢な認証メカニズムを使用して、APIへのアクセスをセキュアに管理します。
   また、ユーザーの権限に基づいてアクセスを制御する認可も重要です。
4. 入力の検証とサニタイズ
    SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃を防ぐため、サーバー側とクライアント側の両方で入力値の検証とサニタイズを行います。
5. 依存関係のセキュリティ
   使用するライブラリやフレームワークのセキュリティ脆弱性に注意し、定期的に更新を行い脆弱性を修正します。

この辺の対策については過去に記事にしていますので時間ある人は読んでみてくださーい

[getpost id=”1618″ cat_name=”1″ date=”0″][getpost id=”1256″ cat_name=”1″ date=”0″]

パフォーマンス

1. コードの分割
   ユーザーが必要とするコードのみをダウンロードするように、コード分割（Code Splitting）を実装します。
   これにより、初期ロード時間を短縮できます。
2. キャッシュ戦略の利用
   静的リソースやAPIレスポンスのキャッシュを適切に利用することで、パフォーマンスを向上させることができます。
   ブラウザのキャッシュやCDNの利用が有効です。
3. 遅延ローディング（Lazy Loading）
    画像やコンポーネントなど、必要になるまでロードしないようにします。
   これにより、初期ロードのパフォーマンスを向上させることができます。
4. APIの最適化
   不必要なデータの送受信を避けるため、APIのレスポンスをできるだけ小さく保ちます。
   また、必要なデータのみを取得するためのフィルタリングやページネーションをAPI側でサポートします。
5. フロントエンドのパフォーマンス最適化
   Reactなどのフロントエンドフレームワークを使用する場合は、不要な再レンダリングを避け、メモ化（memoization）や仮想DOMの効率的な利用などのテクニックを活用します。

セキュリティとパフォーマンスは、アプリケーションの設計と開発の初期段階から考慮する必要があります。
これらの基本的なガイドラインを実践することで、ユーザーに安全で快適な体験を提供することができます。

先日、機能開発のMTG中に先輩からこんな一言がでてきました。

なんじゃそりゃというのがまず最初に思ったことだったのですが、WEB系で働いている以上知っておかなければいけない技術とのことでしたので、勉強しました。

この記事ではRESTful APIについて解説していきまっす。

RESTful APIの主な特徴

ステートレス性

サーバーはクライアントの状態を保存しません。
各リクエストは、それ自体が完全であり、必要なすべての情報を含んでいる必要があります。

クライアント – サーバー構造

クライアントとサーバーは独立しており、お互いにその実装を知る必要がありません。

キャッシュ可能性

レスポンスは、明示的にまたは暗黙的にキャッシュ可能であり、効率的なクライアント-サーバーの相互作用を促進します。

統一インターフェース

システム間の相互作用を簡素化するための一連の原則に従います。

レイヤードシステム

クライアントは、エンドポイントに直接接続しているか、中間サーバーを介して接続しているかを知ることなく、サーバーと通信できます。

HTTPメソッドの使用

RESTful APIでは、リソースの操作にHTTPメソッドが使用されます。主なメソッドは以下の通りです。

• GET: リソースを取得します。
• POST: 新しいリソースを作成します。
• PUT: リソースを更新します。
• DELETE: リソースを削除します。

リソース指向

RESTful APIでは、すべてはリソースとして表されます。リソースは一般的にはデータベースのレコードやオブジェクトの一つ一つを指し、URI（Uniform Resource Identifier）によって一意に識別されます。

例えば、https://example.com/users/1 は、IDが1のユーザーを指すリソースです。

状態レスな通信

RESTful APIのステートレスな通信は、サーバーがクライアントの状態を保持しないことを意味します。

これにより、サーバーの設計が単純になり、スケーラビリティが向上します。各リクエストは、それ自体で完全でなければならず、認証情報やリクエストに必要なデータを含む必要があります。

RESTful APIの利点

• スケーラビリティ
  ステートレスな通信とクライアント-サーバーの分離により、RESTful APIは大規模な分散システムに適しています。
• 柔軟性
  異なるデータフォーマット（JSON、XMLなど）をサポートすることで、様々なクライアントのニーズに対応できます。
• 簡易性
  HTTPプロトコルに基づくため、理解しやすく、実装が容易です。

結論

RESTful APIは、ウェブ上でのデータ交換とサービスの統合を容易にする強力なツールです。

そのシンプルさ、スケーラビリティ、そして柔軟性により、現代のウェブ開発における標準的なアプローチとなっています

適切に設計されたRESTful APIは、開発者が様々なプラットフォームやデバイス間で効率的に通信できるようにすることで、よりリッチでインタラクティブなウェブアプリケーションの構築を可能にします。

1. SPF（Sender Policy Framework）について
2. SPFの設定方法
3. DKIM（DomainKeys Identified Mail）について
4. DKIMの設定方法
5. SPFとDKIMの併用
6. まとめ

SPF（Sender Policy Framework）について

SPFは、メール送信者が使用しているドメイン名が正規のものであるかを検証するための技術です。つまり、あるドメインから送られてくるメールが、そのドメインの管理者によって認められたサーバーから送信されたものであることを確認する仕組みです。

SPFの設定は、ドメインのDNSレコードにSPFレコードを追加することで行います。
このレコードには、「このドメインからメールを送ることが許可されているIPアドレスは何か」という情報が含まれています。
メールを受け取ったサーバーは、この情報をもとに、メールが正規のサーバーから送られてきたものかを検証します。もし一致しなければ、そのメールはスパムやフィッシングの可能性が高いとみなされ、適切に処理されます。

SPFの設定方法

SPFの設定は、基本的にはドメインのDNS設定にSPFレコードを追加することで行います。以下は、SPFレコードの設定手順の概要です。

1. SPFレコードの作成：
   • SPFレコードは、v=spf1から始まります。これに続けて、メールを送信することが許可されているIPアドレスやドメイン、ポリシーを指定します。
   • 例えば、v=spf1 ip4:123.456.789.0/24 -allというレコードは、123.456.789.0/24からのメール送信を許可し、それ以外からの送信は拒否することを意味します。
2. DNSレコードへの追加：
   • ドメインの管理画面にログインし、DNS設定セクションを探します。
   • 新しいTXTレコードを作成し、先ほど作成したSPFレコードの値を入力します。
   • 設定を保存し、変更が適用されるのを待ちます（数時間かかることがあります）。

DKIM（DomainKeys Identified Mail）について

DKIMは、メールが送信途中で改ざんされていないことを確認するための技術です。
メールの送信者は、メールにデジタル署名を加えます。この署名は、送信者のドメインに関連付けられた公開鍵を使って検証することができます。公開鍵は、同じくドメインのDNSレコードに追加されます。

メールを受信した側は、この公開鍵を用いてデジタル署名を検証します。
もし署名が正しく検証できれば、メールは途中で改ざんされていないとみなされ、信頼性が高いと判断されます。このプロセスにより、メールの送信者が本当に主張しているドメインの管理者であること、そしてメール内容が改ざんされていないことが確認されます。

DKIMの設定方法

DKIMの設定は、少し複雑で、メールサーバーでの設定変更が含まれます。以下は、DKIMを設定する基本的なステップです。

1. DKIM鍵の生成：
   • DKIM公開鍵と秘密鍵のペアを生成します。この作業は、使用しているメールサーバーのソフトウェアによって異なります。多くの場合、メールサービスプロバイダーがこれをサポートしており、自動的に行われます。
2. 公開鍵をDNSレコードに追加：
   • 公開鍵をドメインのDNSレコードにTXTレコードとして追加します。これにより、メールを受信した側が、送信されたメールのDKIM署名を検証できるようになります。
   • レコード名は通常、default._domainkeyのような形式で、_domainkeyはDKIMの標準です。値は公開鍵です。
3. メールサーバーの設定：
   • メールを送信する際に、DKIM署名をメールに自動的に追加するよう、メールサーバーを設定します。これは、メールサーバーの設定ファイルで指定するか、メールサービスプロバイダーの指示に従います。

SPFとDKIMの併用

SPFとDKIMは、それぞれ異なるアプローチでメールセキュリティを向上させます。

SPFは送信者のドメインが正しいかを検証し、DKIMはメールの内容が改ざんされていないことを保証します。これら二つの技術を組み合わせることで、より強固なメールセキュリティ体制を築くことができます。

特に、フィッシング詐欺やスパムメールは巧妙化しているため、送信者の正当性を検証し、メールの内容が安全であることを確認することが非常に重要です。SPFとDKIMを適切に設定することで、これらの脅威からユーザーを守る助けとなります。

まとめ

SPFとDKIMは、メールの安全性を確保するための重要な技術です。これらを正しく理解し、適切に設定することで、フィッシングやスパムから自分自身や組織を守ることができます。今回の記事が、SPFとDKIMの基本を理解し、より安全なメール環境を構築するきっかけになれば幸いです。

カメラやスマホでパシャリと一枚撮影するたびに、写真には見えない情報がたくさん詰まっているんですよ。そう、それがExifデータ。

Exifデータって何？

Exifってのは「Exchangeable Image File Format」の略で、デジタル画像ファイルに付加されるメタデータのこと。

カメラの種類、撮影日時、使用したレンズ、露出時間、さらにはGPS情報まで、あらゆる情報が含まれています。

実はこのExifデータ、写真をもっと深く理解する鍵を握っているんです。

例えば、プロの写真家はExifデータを見て、その写真がどのような条件で撮影されたかを分析することができます。
趣味の写真家にとっても、なぜあの写真が上手く撮れたのか、その理由をExifから読み解くことができるんですね。

でも、ちょっと待って！問題もあるんです

しかし、便利な一方で、Exifデータにはちょっとした問題も。
特にプライバシーに関わる部分ですね。

位置情報が含まれていることが多いので、例えば旅行の写真をそのままSNSにアップすると、いつどこで撮影されたかが丸わかり。
時には自宅の場所がバレてしまうこともあるんです。

Exifデータの安全な管理

では、このExifデータ、どうやって安全に管理するのかというと、いくつか方法があります。

一番手軽なのは、専用のソフトウェアやアプリを使ってExifデータを削除すること。また、多くのソーシャルメディアはアップロード時にExifデータを自動的に削除してくれますが、100%頼るのは危険です。自分で確認する癖をつけましょう。

Exifデータの楽しみ方

最後に、Exifデータを楽しむ方法もお話ししておきましょう。
自分の写真のExifデータを見返してみると、その時の思い出が鮮明によみがえってくることも。
また、写真撮影のスキルアップにも役立ちます。同じ場所で同じ被写体を撮るとき、前回のExifデータを参考にしてみるのもいいですね。

Exifデータは、デジタル写真の世界における小さな宝物。
上手に扱うことで、写真をもっと楽しむことができるし、安全に保つこともできます。ぜひ、みなさんもExifデータに注目してみてください！

都内で自社サービス開発に携わっていますやんやんと申します。

フロントもバックも触る傍ら便利だなぁと気付いたTipsについて紹介しますぅ。

今回は File の input についてですぅ。

HTMLのaccept属性について

HTMLの accept 属性は、フォームの <input> タグにおいて使用され、ユーザーがファイルを選択する際にどの種類のファイルを選択できるかをブラウザに指示するために使われます。

accept 属性は、主に次のような値を受け入れます。

• ファイルタイプ指定
• MIMEタイプ (MIME Types): 特定

要件として「CSVだけ受け付けたい」「画像はjpeg,pngのみを受け付けたい」といった内容がアガってきた時にフロントでできる施策になるんじゃないでしょうかぁ〜〜

使用例

ファイルタイプの指定

<!-- すべての画像ファイル形式 -->
<input type="file" accept="image/*">

<!-- すべての音声ファイル形式 -->
<input type="file" accept="audio/*">

<!-- すべてのビデオファイル形式 -->
<input type="file" accept="video/*">

MIMEタイプ (MIME Types)の指定

<!-- JPEG形式の画像ファイルのみを受け入れ -->
<input type="file" accept="image/jpeg">

<!-- application/pdf はPDFファイル -->
<input type="file" accept="application/pdf">

複数の指定

カンマ区切りしてね

<input type="file" accept="image/ping, image/jpeg">

acceptを指定した場合の挙動

ローカルのファイルフォルダーが以下のような形で開かれます。

今回は以下のようなacceptを指定しました。ちゃんと指定のファイルのみが選択できるようになっていますね。ちょっと便利。

<input type="file" accept="text/csv">

目的

影響を与えることができなさそうですが、UXの向上を狙えます。笑

ただしフロント側で制限できるとはいえ、サーバーにアップロードする方法はいくらでもあるので、バックエンドでバリデーションはしっかり行ってくださいね

参考

https://developer.mozilla.org/ja/docs/Web/HTML/Attributes/accept

今日はちょっとマニアックな話、ステートフルとステートレスについてお話ししたいと思います。
これ、聞いたことあるけどよくわからないって人、多いんじゃないかな？
でも大丈夫、ここでしっかり理解していきましょう！

ステートフルって何？

まずはステートフルについて。

ステートフルっていうのは、端的に言うと「過去の情報を覚えている状態」のこと。
システムが過去にどんな処理をしたかを記憶していて、それをもとに次の動作を決めるんです。

例えば、Webサイトにログインする時を考えてみてください。
一度ログインすると、そのサイトは「あ、この人はもう認証済みだな」と覚えてくれてますよね。
これがステートフルな動作。ユーザーの状態を保持して、その情報に基づいて何らかの処理をするわけです。

具体例

1. Webセッション管理：
   ユーザーがWebサイトにログインしたとき、サーバーはそのユーザーのセッション情報（例えば、認証情報、プロファイル設定など）を保持します。この情報は、ユーザーがサイトをナビゲートする間、持続し、適切なコンテンツやオプションを提供するために使用されます。
2. データベーストランザクション：
   データベースは、過去のクエリやトランザクションの履歴を追跡し、それに基づいてデータの整合性を保持します。たとえば、銀行の取引記録は、口座の残高を正確に保つために重要です。

じゃあステートレスって？

一方で、ステートレスはその逆。

つまり、「過去の情報を覚えていない状態」を指します。
こっちは、過去の情報に左右されずに、その都度独立して処理を行います。

たとえば、HTTPプロトコル。
これ、実はステートレスなんですよ。
ウェブサーバーは、同じユーザーからのリクエストでも、それぞれを完全に別々のものとして扱うんですね。だから毎回、ページをリロードするたびに「誰この人？」ってなるわけです。

具体例

1. HTTPプロトコル：
   HTTPはステートレスプロトコルです。ウェブサーバーは、同一のクライアントからの複数のリクエストを関連づけません。各リクエストは独立しており、サーバーはそれぞれのリクエストを新規のものとして処理します。
2. RESTful API：
   RESTアーキテクチャはステートレスであり、各APIリクエストは他のリクエストから独立しています。例えば、REST APIを通じてリソースを取得するリクエストは、以前のリクエストやその結果とは無関係に処理されます。

ステートフルとステートレス、使い分けは？

これら二つ、どちらが良いとか悪いとかではなくて、用途によって使い分けるのが大事。

ステートフルは、ユーザーに合わせたカスタマイズや複雑な処理が必要な場合に向いています。
一方、ステートレスはシンプルさとスケーラビリティが求められる場合、例えば大規模なWebサービスとかにぴったり。

要は、状況に応じて臨機応変に使い分けることが大切。
システム設計する時は、この二つの特性をよく理解して、最適なアーキテクチャを選んでいきましょう！

まとめ

いかがでしたか？
ステートフルとステートレス、ちょっと難しいけど、この話を押さえておけば、システムの動きを理解するのに役立つはず。

ぜひこの知識を活用して、もっとITの世界を楽しんでいってくださいね！それでは、また次回！

1. ある日の出来事
2. 原因はiCloud

ある日の出来事

チームに所属するインターン生から1つの相談がありました。

「やんやんさん、プログラムが動きません。。。」

最初は「実行エラーだろう、エラー文言に何が書いてあるのか読めよ」と思っていたのですが、エラーの内容を読むと事態は思ったよりも深刻であることに気づきます。

原因はiCloud

原因はプログラムの配置場所がiCloudで管理しているDesktopに置いていることでした。

Gitで管理しているソースコードがiCloudとの同期が取れておらず、ファイルの増減がありプログラムが正常に動作しないという問題です。

Git（リモートリポジトリからのpull, ブランチの切り替え等）で管理しているはずのソースコードが裏ではiCloudでも管理されていたという間抜けな話でした。

みなさんもご注意を。。。。

1. セキュリティを担保したつもりが
2. 何が良くないのか？
3. 対策
4. 預かったデータは大切に

セキュリティを担保したつもりが

有効なメールアドレスかどうかを検証するために以下のような流れで処理を組むことはよくあると思います。

1. メールアドレス入力（ユーザー）
2. ランダムな文字列を入力されたメールアドレスに送信（システム）
3. 受け取ったランダムな文字列を入力（ユーザー）
4. ユーザーが入力した文字列を送信した文字列と一致するか判定（システム）
5. 4の検証が正常に通過したら1で入力されたメールアドレスを有効なアドレスとして登録

そうですよね。メールアドレスの検証は絶対必要ですよね。
上記の流れに間違いはないはずです。

レビューを貰うまで完璧な実装をしたと思い込んでいました。

何が良くないのか？

問題になったのは、1で実施するユーザーが入力したメールアドレスの検証です。

ユーザーが入力したメールアドレスの検証では、以下の検証を実施しなければいけません。

1. メールアドレス形式か
2. DBに登録されていないメールアドレスか
3. 必要であればその他バリデーション

僕が実装した内容で問題となったのは、2のDBに登録されていないメールアドレスです。

僕の実装内容では、DBに登録されているメールアドレスが入力されたら「既に登録済みのメールアドレスです」とバリデーションエラーを出力していました。

それって、バリデーションに引っかかったメールアドレスが既に使用されている誰かのメールアドレスだと世に発表してしまっている状況でした。

具体的に以下の事象を引き起こしてしまう問題です。

1. バリデーションに引っかかったメールアドレスを用いて総当たり攻撃に使用される（ログインなど）
2. バリデーションに引っかかったメールアドレスを自分が管理しているシステム以外で使用される

1に関しては試行回数に制限をかければ問題ないのですが、2に関しては僕らが出来ることは何一つ有りません。
だって、自分らが管理しいない場所で悪用されるからです。

ここで取得されたメールアドレスを悪意のある業者に売ったり、取得した悪意のある人がよからぬメールを送信することが出来ちゃいます。

なんて恐ろしい事態に陥ってしまうのでしょう。。

対策

対策は色々あると思いますが、僕が思いつくやつ挙げていきます。

• 「無効な値です。」というバリデーションエラーを出力
  • 既に使われている事を明記しない
  • 正確な対策ではない
• 認証メールに添付するエンドポイントを絶対に検証が通らないエンドポイントにする
  • ランダム文字列を入力するフォームに特定の条件のみアクセス可能とするなどが必要（ちょっと面倒）

他にもあるはずなので、各自のシステムに合わせて実装してください。

預かったデータは大切に

良かれと思って実装した内容がユーザーの個人情報を危険に晒してしまうことがあることを学べた貴重な経験でした。

やりがちなミスだと思うので、皆様もお気をつけください。