1つのリポジトリ内でフロントエンドとサーバーのコードをディレクトリ分割の形式で管理していましたが、色々と辛くなってきたので、リファクタしてモノリポ化しました。 
その時に考慮した事をまとめています。
※ リファクタ後のリポジトリはプライベートリポジトリなので公開していません。
<h2 id="開発環境">開発環境</h2>
フロントエンドのフレームワークとしてNext.jsを利用しており、外部へのAPIリクエストのプロキシを目的としてBFFをNext.jsのカスタムサーバーとしてexpressを用いて実装しています。
<ul>
<li>BFF: TypeScript, Node.js, express（Next.jsのカスタムサーバー）</li>
<li>フロントエンド: TypeScript, Next.js</li>
</ul>
<h3 id="初期構成">初期構成</h3>
リファクタ前の構成は次のようになっており、ディレクトリ分割によりフロントとサーバーのコードを管理している状態でした。
<pre><code>.
├── .storybook
├── pages
├── public
├── src
│ ├── client
│ ├── common
│ ├── config
│ ├── server
│ └── types
├── stories
├── test
│ ├── src
│ │ ├── client
│ │ ├── common
│ │ └── server
│ └── tsconfig.json
├── next.config.js
├── nodemon.json
├── package.json
├── server.ts
├── tsconfig.json
├── tsconfig.common.json
└── tsconfig.server.json
</code></pre>
<h3 id="初期構成の問題">初期構成の問題</h3>
初期のディレクトリ構成ではルートに大量のファイルやディレクトリが存在していて、初見で見た時にどのファイルやディレクトリがフロントとサーバーのどちらに関係しているのか非常に分かり辛い状態でした。また <code>src</code> や <code>test</code> の中で <code>server</code> と <code>client</code> でディレクトリを分けていますが、フロントとサーバーではTypeScriptの設定が異なるため、tsconfigの設定も複雑化していました。 
※ 説明のために省略していますが、実際は他にもDockerのディレクトリなども存在します。
<h2 id="モノリポ化">モノリポ化</h2>
<h3 id="利用ツールの検討">利用ツールの検討</h3>
今回は yarn workspace のみを利用してモノリポ化を進めました。
モノリポ化で利用されるライブラリとしては <a href="https://github.com/lerna/lerna" target="_blank">lerna</a> が有名ですが、採用を見送りました。今回のケースでは yarn workspace のみで目的が達成できたのと、lerna が BabelなどのOSSプロジェクト（一般に公開する前提のプロジェクト）をモノリポ化する目的で作られているように見え、プライベートなリポジトリでは冗長かつ依存ツールを追加して管理コストが増える事は避けたかったからです。
フロントとサーバーをモノリポで管理するツールとして <a href="https://nx.dev/react" target="_blank">Nx</a> も検討しましたが、簡単に触った感じでは想像以上にフルスタックな印象を受け、Nx のディレクトリ構成に従う必要がありそうで、既存プロジェクトの移行コストが非常に高そうだったので見送りました。
参考として、 <a href="https://codewithhugo.com/yarn-workspaces-application-monorepo/" target="_blank">Yarn Workspaces: monorepo management without Lerna for applications and coding examples</a> とかの記事もありました。
<h3 id="TypeScript Project Reference">TypeScript Project Reference</h3>
モノリポ化にあたり、TypeScript の <a href="https://www.typescriptlang.org/docs/handbook/project-references.html" target="_blank">Project Reference</a> を新たに導入しました。これは、TS3.0 から追加された仕組みでTypeScriptのプロジェクトを独立して管理する事ができます。モノリポによりパッケージを分割するので、合わせてTypeScriptのビルドなどもパッケージ単位で分割したくて導入しました。
モノリポ環境では、@app/web =&gt; @app/server と依存している時に、@app/web を先にビルドすると、@app/server がビルドされておらずモジュール解決に失敗する問題が発生する可能性があります。Project Reference を導入すると、<code>tsc --build</code> と実行することで、@app/web をビルドする時に合わせて @app/server を必要に応じてビルドしてくれるので、依存関係の問題を解消する事もできます。
<h3 id="最終構成">最終構成</h3>
モノリポ化した後のディレクトリ構成は次のようになりました。フロントとサーバーがパッケージ単位で分割されて関連する設定ファイルやディレクトリもパッケージでまとめられたので、非常に見通しが良くなりました。
<pre><code>├── workspaces
| ├── common 複数のパッケージから共通で利用するパッケージ
| │ ├── src ソースコード置き場
| | ├── package.json
| | └── tsconfig.json 
| ├── config 設定ファイルを保持するパッケージ
| │ ├── index.ts バレルファイル
| │ ├── firebase.ts 
| | ├── package.json
| | └── tsconfig.json TypeScriptの設定ファイル
| ├── server サーバー側のパッケージ
| │ ├── src ソースコード置き場
| │ ├── test テストコード置き場
| │ ├── types 型定義ファイル置き場
| | ├── package.json
| | └── tsconfig.json 
| ├── web
| | ├── .storybook Storybookの設定ファイル置き場
| | ├── public 画像などの公開ファイル置き場
| | ├── pages Next.jsのページコンポーネント置き場
| | ├── src
| | ├── stories Storybookのストーリーファイル置き場
| | ├── test テストコード置き場
| | ├── next.config.js Next.jsの設定ファイル
| | ├── nodemon.json 開発環境でのNext.jsのカスタムサーバー自動起動の設定
| | ├── package.json
| | ├── server.ts Next.jsのカスタムサーバー（実装はserverパッケージを参照）
| | ├── tsconfig.json
| | └── tsconfig.server.json
| └── tsconfig.json
└── pakcage.json
</code></pre>
<code>web</code> パッケージの package.json と tsconfig.json の一部です。
<pre class="language-json"><code class="language-json"># web/package.json

{
 "dependencies": {
 "@app/server": "*"
 }
}
</code></pre>
<pre class="language-json"><code class="language-json"># web/tsconfig.json

{
 "extends": "../tsconfig.json",
 "references": [
 { "path": "../server" }
 ]
}
</code></pre>

ディレクトリ分割でフロントエンドとサーバーのコードを管理していたリポジトリをリファクタしてモノリポ化した時のまとめ。

TypeScriptプロジェクトをモノリポ化した時のまとめ

ISUCON 夏季講習 2017をやり、ボトルネック発見までの基本的なデータ収集の部分だけをまとめました。

ISUCONの夏季講習2017をやった

CDK for Terraform のチュートリアルを TypeScript で試してみました。 
<a href="https://www.hashicorp.com/blog/cdk-for-terraform-enabling-python-and-typescript-support/" target="_blank">CDK for Terraform: Enabling Python &amp; TypeScript Support</a>
<h2 id="Terraformのインストール">Terraformのインストール</h2>
<a href="https://learn.hashicorp.com/terraform/getting-started/install.html" target="_blank">Install Terraform | Terraform - HashiCorp Learn</a>
<pre class="language-shell"><code class="language-shell">$ brew install terraform
</code></pre>
<h2 id="CDK for terraform のインストール">CDK for terraform のインストール</h2>
<pre class="language-shell"><code class="language-shell">$ yarn global add cdktf-cli
</code></pre>
<h2 id="AWSでVPCを構築するチュートリアル">AWSでVPCを構築するチュートリアル</h2>
<h3 id="プロジェクトの作成">プロジェクトの作成</h3>
Terraform Cloud でリモートステートを管理するか聞かれるので &quot;no&quot; とする。
<pre class="language-shell"><code class="language-shell">$ mkdir vpc-example
$ cd vpc-example
$ cdktf init --template=typescript
...
Do you want to continue with Terraform Cloud remote state management (yes/no)? no
Project Name: (default: 'vpc-example')
Project Description: (default: 'A simple getting started project for cdktf.')
</code></pre>
<h3 id="実装">実装</h3>
TerraformのHCLと比較すると、型のおかげで必須オプションの漏れなどが、リアルタイムで分かるのは良いですね。
<pre class="language-typescript"><code class="language-typescript">import { Construct } from 'constructs';
import { App, TerraformStack, Token } from 'cdktf';
import { Vpc } from './.gen/providers/aws/vpc';
import { Subnet } from './.gen/providers/aws/subnet';
import { AwsProvider } from './.gen/providers/aws'

class MyStack extends TerraformStack {
 constructor(scope: Construct, name: string) {
 super(scope, name);

 new AwsProvider(this, 'aws', {
 region: 'ap-northeast-1'
 });

 const vpc = new Vpc(this, 'my-vpc', {
 cidrBlock: '10.0.0.0/16'
 });
 new Subnet(this, 'my-subnet', {
 vpcId: Token.asString(vpc.id),
 cidrBlock: '10.0.0.0/24'
 });
 }
}

const app = new App();
new MyStack(app, 'vpc-example');
app.synth();
</code></pre>
<h3 id="TerraformのJSONファイルを生成">TerraformのJSONファイルを生成</h3>
TypeScriptのコードからTerraformのJSON形式の設定ファイルをに生成します。ファイルは<code>cdk.tf</code>ディレクトリに出力されます。
<pre class="language-shell"><code class="language-shell">$ cdktf synth
Generated Terraform code in the output directory: cdktf.out

$ tree cdktf.out
cdktf.out
└── cdk.tf.json
</code></pre>
<h3 id="Terraformを実行">Terraformを実行</h3>
生成された設定ファイルを元に terraform を実行することで、AWSにVPCを構築できます。 
設定がまだの場合は事前に <code>aws configure</code> で設定を完了させておく必要があります。
AWSコンソールのVPCを確認すれば、新しくリソースが作成されている事が確認できます。
<pre class="language-shell"><code class="language-shell">$ cd cdktf.out
$ terraform init
$ terraform plan
...
# 追加されるVPCの情報が表示される

$ terraform apply
aws_vpc.vpcexample_myvpc_80A1790F: Creating...
aws_vpc.vpcexample_myvpc_80A1790F: Still creating... [10s elapsed]
aws_vpc.vpcexample_myvpc_80A1790F: Creation complete after 10s [id=vpc-09aeca6257ae5fe31]
aws_subnet.vpcexample_mysubnet_3769B309: Creating...
aws_subnet.vpcexample_mysubnet_3769B309: Creation complete after 3s [id=subnet-0264b990708ed4f69]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
</code></pre>
<h3 id="リソースの削除">リソースの削除</h3>
最後に今回のチュートリアルで作成したVPCを削除しておきます。
<pre><code>$ terraform destroy
</code></pre>

CDK for Terraform でVPCを構築するチュートリアルです

CDK for Terraform でVPCを構築するチュートリアル

Rustで標準出力に色を付けるだけなら、次のように書けば可能です。ただ、コードにこのまま書くのは保守性の面でも避けたいです。
<pre class="language-rust"><code class="language-rust">fn main() {
 let output = "Hello, World";
 println!("\x1b[38;5;1m{}\x1b[m ", output);
}
</code></pre>
<h2 id="mackwic/colored">mackwic/colored</h2>
<a href="https://github.com/mackwic/colored" target="_blank">mackwic/colored</a> はターミナルの標準出力の色付けが簡単にできるクレートです。 
これを利用すれば、簡単に実装ができます。
<h4 id="インストール">インストール</h4>
<pre><code class="language-toml">[dependencies]
colored = &quot;1.9&quot; # バージョンは随時更新してください
</code></pre>
<h4 id="使い方">使い方</h4>
<pre class="language-rust"><code class="language-rust">use colored::*;

fn main() {
 let output = "Hello, World";
 println!("{}", output.red());
 println!("{}", output.blue().bold());
}
</code></pre>

Rustで標準出力に色を付ける

前に Ajax でフォームの送信をする時に form と div どちらを使うのが良いのか？という質問をされました。質問の意図としては、form タグで実装した場合は送信イベントを止めるために <code>preventDefault()</code> を呼ぶ必要があり、この処理を毎回呼ぶのが面倒なので挙動が変わらないなら div タグ の方が良いのでないか？という話でした。
結論だけ先に書いておくと form タグを使おう です。
div タグでの実装例
<pre class="language-html"><code class="language-html">&lt;script>
 const button = document.getElementById('send');
 button.addEventListener('click', () => {
 // inputの値を取得してデータバリデーションとかする
 fetch(...);
 });
&lt;/script>

&lt;div id="form">
 &lt;input type="text" id="name" />
 &lt;div>
 &lt;button id="send">send&lt;/button>
 &lt;/div>
&lt;/div>
</code></pre>
form タグでの実装例
<pre class="language-html"><code class="language-html">&lt;script>
 const form = document.getElementById('form');
 form.addEventListener('submit', (event) => {
 event.preventDefault();
 // inputの値を取得してデータバリデーションとかする
 fetch(...);
 });
&lt;/script>

&lt;form id="form">
 &lt;input type="text" id="name" />
 &lt;div>
 &lt;button type="submit" id="send">send&lt;/button>
 &lt;/div>
&lt;/form>
</code></pre>
<h2 id="form タグと div タグの違い">form タグと div タグの違い</h2>
form タグで実装した場合は以下の挙動がブラウザのデフォルトとして動作します。
<ol>
<li>キーボードの Enter を押してリクエストの送信ができる</li>
<li>type=&quot;password&quot; を含むフォームの送信が成功したら、ブラウザのパスワード保存を自動で確認してくれる</li>
</ol>
div タグで実装した場合はこれらを自前で実装する工数が発生します。
<ol>
<li>Enter キーのイベントを監視してコールバックを登録する。</li>
<li>ブラウザのパスワード保存の確認は API 経由で出来るのか不明</li>
</ol>
特に 2 つめのパスワード保存については、簡単に調べた感じだと API が提供されていないので、対応ができない可能性が高い気がします。 
このようにブラウザのデフォルトの挙動を考えると、フォームを div タグ で実装するメリットはあまりなく、特別な理由が無ければ素直に form タグ で実装しておいた方が良いです。

フォーム実装にformタグを使うかdivタグを使うか

<a href="https://github.com/alievk/avatarify" target="_blank">alievk/avatarify: Avatars for Zoom and Skype</a>
この記事は MacOS でのセットアップ方法を記述しています。 
環境でセットアップ手順が異なるので、LinuxやWindowsの場合はリポジトリのREADME.mdを参照してください。
【環境】 
OS: MacOS Catalina 10.15.3 
端末: MacBook Pro 2017 
プロセッサ: 2.3 GHz デュアルコアIntel Core i5 
メモリ: 16 GB 2133 MHz LPDDR3 
グラッフィックス: Intel Iris Plus Graphics 640 1536 MB 
GPU: なし
<h2 id="インストール">インストール</h2>
<h3 id="miniconda3 をインストール">miniconda3 をインストール</h3>
<a href="https://docs.conda.io/projects/conda/en/latest/user-guide/install/macos.html#installing-on-macos" target="_blank">Installing on macOS — conda 4.8.3.post14+07a113d8 documentation</a>
<a href="https://docs.conda.io/en/latest/miniconda.html#macosx-installers" target="_blank">Miniconda — Conda documentation</a> よりインストーラーをダウンロードする。
<pre class="language-bash"><code class="language-bash"># 対話シェルが起動するので、内容に沿ってインストールを進める。
$ zsh Miniconda3-latest-MacOSX-x86_64.sh
$ export PATH="$HOME/miniconda3/bin:$PATH"
</code></pre>
<h3 id="avatarify のリポジトリをクローンしてインストール">avatarify のリポジトリをクローンしてインストール</h3>
<pre class="language-bash"><code class="language-bash">$ git clone https://github.com/alievk/avatarify.git
$ cd avatarify
$ zsh scripts/install_mac.sh
$ conda activate avatarify
</code></pre>
<h3 id="学習済みモデル vox\-adv\-cpk\.pth\.tar をダウンロード">学習済みモデル vox-adv-cpk.pth.tar をダウンロード</h3>
<a href="https://drive.google.com/file/d/1L8P-hpBhZi8Q_1vP2KlQ4N6dvlzpYBvZ/view" target="_blank">Google ドライブ</a>からダウンロードして avatarify ディレクトリ配置する。 
※ tarファイルは解凍せずにそのまま配置する
<h3 id="CamTwist をダウンロード">CamTwist をダウンロード</h3>
<a href="http://camtwiststudio.com/download/" target="_blank">ここ</a>からダウンロードする
<h2 id="実行">実行</h2>
<h3 id="avatify を起動">avatify を起動</h3>
&quot;Cannot open camera&quot; のエラーが発生したら、scripts/settings.sh の CAMID を 0 から 1, 2, ... に変更する。 
自分の場合は 1 に変更したら、正常に起動しました。
<pre class="language-bash"><code class="language-bash">$ zsh run_mac.sh
</code></pre>
<h3 id="CamTwistを起動">CamTwistを起動</h3>
2.1 「Desktop+」 を選んで Select をクリック 
2.2 Settingsの項目内で 「Confine to Application Window」を選択してセレクトボックスで「Python(avatarify)」を選ぶ
アバターが表示されたウィンドウで 1, 2, ... と数字キーを押せばアバターの切替えができます。
<h3 id="Zoomdでバーチャルカメラを利用できるようにする">Zoomdでバーチャルカメラを利用できるようにする</h3>
Mac の Zoom v4.6.8 以降のバージョンでは仮想カメラが使えないようになっているので、ライブラリ署名を削除して仮想カメラを利用できるようにする。
<pre class="language-bash"><code class="language-bash">$ codesign --remove-signature /Applications/zoom.us.app
</code></pre>
<h3 id="Zoomを起動">Zoomを起動</h3>
4.1 Zoom で 設定 &gt; カメラ &gt; CamTwist を選択
<img src="/images/posts/avatarify/zoom.gif" alt="zoom" loading="lazy" width="1266" height="756">
GPUが無いと ~1FPS しかパフォーマンスが出ないので、動いてはいるのですが全く楽しめないです。😢

Zoomでアインシュタインになってみた

Rust は所有権の機能を導入することでガベージコレクションを実装せずにメモリ安全を実現しています。これを理解しないとコンパイルエラーが発生した時になぜエラーなのかを把握するのか困難になるので、Rust を使う上で重要な概念です。
ドキュメントなどを読み概要が把握できたので、整理のために説明を書いていきます。
<h2 id="所有権の特徴">所有権の特徴</h2>
現在のプログラムにおける一般的なメモリの管理方法は大きく分けて二つあります。 
一つは C や C++のようにプログラマが自分でメモリの確保と開放を宣言するやり方、二つ目は Java や Go のようにベージコレクションによって定期的に不要なメモリを開放する方法です。 
一つ目の方法ではプログラマが常にメモリを意識して開発する必要があり非常にコストがかかり、メモリ管理を誤った場合にダングリングポインタやメモリ 2 重開放などでエラーが発生する危険性があります。また、二つ目の方法では定期的に実行されれるガベージコレクターがアプリケーションの動作の妨げになる事があります。
Rust では所有権システムに基づいてコンパイラがコンパイル時にメモリ安全性のチェックを行うことで、ガベージコレクションを組み込む事なく自動でメモリ安全性を保証しています。
<h3 id="所有権規則">所有権規則</h3>
所有権システムは次の規則を持っています。
<ul>
<li>規則 1: 値は所有者と呼ばれる変数と対応している</li>
<li>規則 2: 値を所有できる変数は必ず一つだけである</li>
<li>規則 3: 値を所有する変数がスコープを抜けたら、値は破棄される</li>
</ul>
<h3 id="メモリと変数スコープ">メモリと変数スコープ</h3>
<pre class="language-rust"><code class="language-rust">fn main() {
 let s1 = String::from("hello"); // ここで
 println!("{}", s1);
} // ここでs1がスコープから抜けるので "hello" の値も破棄される
</code></pre>
ここで登場している String 型 は可変の値なので、コンパイル時にサイズを決定する事ができないので、値はヒープ領域に配置されます。 
このとき「値を所有する変数がスコープを抜けたら、値は破棄される」の規則に則り、s1 がスコープから抜ける時に、&quot;hello&quot; のメモリ解放がされます。
<img src="/images/posts/rust-ownership/memory1.png" alt="memory1" loading="lazy" width="524" height="372">
<h3 id="所有権のムーブ">所有権のムーブ</h3>
次に、変数を別の変数に代入した場合のメモリの状態を考えてみます。
<pre class="language-rust"><code class="language-rust">fn main() {
 let s1 = String::from("hello");
 let s2 = s1;
}
</code></pre>
この状態で先ほどと同じようにメモリの解放を考えてみます。最初に s2 がスコープから抜けるタイミングで、&quot;hello&quot; のメモリが解放されます。次に s1 がスコープから外れるので同じようにメモリを解放します。
この時、他の言語であれば、&quot;hello&quot; のメモリは既に解放されているため、s1 でも同様にメモリ解放を実行すると、無効なメモリを解放する事になるのでエラーが発生します。
<img src="/images/posts/rust-ownership/memory2.png" alt="memory2" loading="lazy" width="524" height="372">
しかし、Rustでは対象のコードはコンパイルに成功して正常に実行されます。 
なぜでしょうか？
ここで最初に紹介した「値を所有できる変数は必ず一つだけである」事を思い出してみます。実は <code>let s2 = s1;</code> の部分で &quot;hello&quot; の所有権が s1 から s2 へ移動しており、s1 は値を所有しておらず変数として無効となっているのです。そのため、Rust は s1 がスコープから抜けるタイミングでメモリ解放をする必要がなくなり、結果として s2 に対してのみメモリ解放が実行されるため、正常に動作します。
この、値を所有する変数が移動することを 所有権のムーブ といいます。
<img src="/images/posts/rust-ownership/move_ownership.png" alt="move_ownership" loading="lazy" width="524" height="372">
この仕組みを考えると、例えば、次のコードはどうなるのでしょうか？
<pre class="language-rust"><code class="language-rust">fn main() {
 let s1 = String::from("hello");
 let s2 = s1;
 -- value moved here
 println!("{}", s1);
 ^^ value borrowed here after move
}
</code></pre>
このコードはコンパイルエラーになります。&quot;hello&quot; の所有権が s1 から s2 にムーブしており、既に無効となっている s1 を使おうとしているためコンパイルエラーになるのです。
また所有権のムーブは関数に値を渡す場合も同様に発生します。
<pre class="language-rust"><code class="language-rust">fn hello(s: String) {
 println!("hello! {}", s);
}

fn main() {
 let name = String::from("taro");
 hello(name);
 ---- value moved here
 println!("{}", name);
 ^^^^ value borrowed here after move
}
</code></pre>
<h3 id="借用">借用</h3>
それでは、先ほどの例で関数に値を渡したい時はどうすればいいのでしょうか？ 
この問題は 借用 を使う事で解決できます。借用は <code>&amp;</code> を使って表現します。
<pre class="language-rust"><code class="language-rust">fn hello(s: &amp;String) {
 println!("hello! {}", s);
}

fn main() {
 let name = String::from("taro");
 hello(&amp;name);
 println!("{}", name);
}
</code></pre>
借用は name への参照を作成し、これを所有しません。つまり、s は所有権を持たないのでスコープを抜けてもメモリ解放は実行されず、name がスコープを抜けたタイミングでメモリ解放が実行されます。 
これは、コンパイラに対して「s は値を借りているだけなので、スコープを抜けてもメモリの解放をする必要がないよ」と教えているのです。
メモリ状態を表現すると次のようになります。
<img src="/images/posts/rust-ownership/memory3.png" alt="memory3" loading="lazy" width="742" height="372">
この借用を用いることで、所有権をムーブさせずに値を参照することができます。
<h2 id="参考">参考</h2>
<ul>
<li><a href="https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html" target="_blank">What is Ownership? - The Rust Programming Language</a></li>
<li><a href="https://doc.rust-jp.rs/book/second-edition/ch04-01-what-is-ownership.html" target="_blank">所有権とは？ - The Rust Programming Language</a> （公式の日本語翻訳）</li>
</ul>
<h2 id="まとめ">まとめ</h2>
Rust の所有権と借用の仕組みは理解するのに、かなり時間がかかりました。理解すると意外とシンプルな考えなんだなと感じました。 
この記事は参考ドキュメントで理解した事を自分用に噛み砕いて書いただけなので、詳しい説明はドキュメントを読んだ方が良いです。

Rustの所有権と借用を理解する

フロントエンド実装においてセキュリティを考慮する際に意識した方が良いHTTPレスポンスヘッダーについてまとめています。
<h2 id="X-Powered-By">X-Powered-By</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
サーバー側で利用しているフレームワークやバージョン情報を含むHTTPヘッダー
<pre><code>例: 
X-Powered-By: Next.js
</code></pre>
<h3 id="脆弱性">脆弱性</h3>
サーバー側で利用されているフレームワークやバージョンが含まれているため、他に脆弱性が存在した場合に攻撃者に攻撃を助ける情報を与える可能性がある。
<h3 id="対策方法">対策方法</h3>
サーバー側で X-Powered-By ヘッダーを出力しないように設定する。
<h2 id="X-Runtime">X-Runtime</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
サーバーの応答時間を含むHTTPヘッダー
<pre><code>例: 
X-Runtime: 0.094235
</code></pre>
<h3 id="脆弱性">脆弱性</h3>
タイミング攻撃（Timing Atacking）に利用される可能性がある。
<h3 id="タイミング攻撃">タイミング攻撃</h3>
サーバーの応答時間の違いを利用する事でサービスを分析する攻撃手法です。 
例えば、次のようにログイン処理が実装されていたとします。
<pre class="language-typescript"><code class="language-typescript">const login = (user_name, password) => {
 const user = User.get(user_name);
 if (user == null) return res.send(400);

 // 登録済みのユーザー名の場合はパスワードチェク処理が実行される分だけ応答時間が長くなる
 const mached = user.matchPassword(password);
 if (matched) res.send(200);
 else res.send(400);
}
</code></pre>
この時、ユーザー名がサービスに登録済みの場合はパスワードチェック処理が追加で実行される影響で応答時間が少し長くなるため、攻撃者はランダムなユーザー名でリクエストを送信して X-Runtime の応答時間の違いを比較することで、サービスに登録済みのユーザー名を特定する事ができます。
<pre><code># 未登録のユーザー名の場合
X-Runtime: 0.3949

# 登録済みのユーザー名の場合
X-Runtime: 0.6421
</code></pre>
参考: <a href="https://www.virtuesecurity.com/kb/x-runtime-header-timing-attacks/" target="_blank">X-Runtime Header Timing Attacks - Virtue Security</a>
<h3 id="対策方法">対策方法</h3>
X-Runtime ヘッダーを出力しないように設定する。
<h2 id="Cache-Control">Cache-Control</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
キャッシュの生存期間や保存可否などを制御するHTTPヘッダー 
HTTPレスポンスヘッダーとして指定された場合は、サーバーからのレスポンスを Cache-Control の指定に基づいて制御する。
<pre><code>例 画像などを1日キャッシュする
Chach-Control: max-age=86400
</code></pre>
<h3 id="脆弱性">脆弱性</h3>
ブラウザは何の指定も無い場合はデフォルトでサーバーレスポンスを可能な場合にキャッシュします。 
この時サーバーレスポンスにユーザーのパスワード情報などが含まれていた場合に、何らの方法で攻撃者がユーザーの物理マシンにアクセス可能な状態であれば、マシンに保存されているブラウザキャッシュなどからパスワード情報を盗み出される可能性がある。
<h3 id="対策方法">対策方法</h3>
Cache-Control を指定して、扱う情報に応じた適切なキャッシュ制御を行う。 
例えば、ユーザーの端末に保存するべきでない情報を含む場合は <code>nostore</code> を指定してキャッシュを保存しないようにする。
<pre><code>Cache-Control: nostore
</code></pre>
<h2 id="X-Frame-Options">X-Frame-Options</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/X-Frame-Options" target="_blank">X-Frame-Options - HTTP | MDN</a>
ブラウザが自分のWebページを &lt;iframe&gt; や &lt;object&gt; の中へ表示することを禁止することで、Webページが他のサイトに埋め込まれないことを保証することができます。
<h3 id="脆弱性の説明">脆弱性の説明</h3>
適切に設定していない場合にクリックジャッキング攻撃に利用される可能性がある。
<h3 id="クリックジャッキング攻撃">クリックジャッキング攻撃</h3>
外部ページを埋め込んだiframeを透明化して通常のWebページの上に被せることで、攻撃者がユーザーに意図しない操作をさせる攻撃手法です。
例えば、次の要件を満たすようなサービスをユーザーが利用しているとします。
<pre><code>1. ログイン情報をCookieで管理している
2. same-site属性はnone
3. アカウント画面の削除ボタンを押すだけで確認なしでアカウントが削除できる
</code></pre>
このとき対象サービスのアカウントページをiframeに埋め込み透明化した状態でWebページの上に重ねた場合、ユーザーがログイン済みであればユーザーのアカウントページが透明な状態で上に重なって表示されます。 
対象サービスの削除ボタンに重なる位置にクリックしたくなるようなリンクを配置することで、ユーザーに削除ボタンをクリックさせて、アカウントを削除するように誘導する事ができます。
<h3 id="対策方法">対策方法</h3>
<code>X-Frame-Options: Deny</code> を指定する事で iframe 等へのページの埋め込みを禁止する。
<h2 id="Content-Security-Policy（CSP）">Content-Security-Policy（CSP）</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/CSP" target="_blank">コンテンツセキュリティポリシー (CSP) - HTTP | MDN</a>
インラインスクリプトの実行を禁止してXSSなどの攻撃を軽減する事ができます。
例えば、次のようにHTTPレスポンスヘッダーに含める事で、掲示板のサービスなどでサニタイズ処理をせず任意の文字列をサービスに埋め込める脆弱性があった場合でも、インラインスクリプトの実行ができないためXSS攻撃を軽減する事ができます。
<pre><code># 外部ドメインのファイル読み込みやインラインスクリプトの実行を禁止する
Content-Security-Policy: default-src 'self'
</code></pre>
IEは CSPの sandbox ディレクティブのみが利用可能になっており、IE9以下は CSP 未対応なので、次に紹介する X-XSS-Protection を利用する必要があります。
詳しい設定は上記のMDNのリンクを参照してください。
<h3 id="脆弱性の説明">脆弱性の説明</h3>
掲示板などでユーザーが入力した値をサニタイズせずに画面上に表示していた場合にXSS攻撃を仕込まれる可能性がある。
<h3 id="注意点">注意点</h3>
外部ドメインからのスクリプト読み込みを禁止した場合に、CDN経由でのライブラリ読み込みなどが出来なくなってしまいます。 
そのため、自身のサービスの特性に合わせて適切に設定する必要があります。
例えば、次の設定をする事で自身のドメインと特定ドメインの CDN からのみスクリプト読み込みを許可する事ができます。
<pre><code>Content-Security-Policy: default-src 'self' cdnjs.cloudflare.com
</code></pre>
<h3 id="対策方法">対策方法</h3>
Content-Security-Policyを適切に設定する。
※ CSPの設定とは別でユーザーが入力した値を表示する箇所で適切にサニタイズ処理はするべきです。
<h2 id="X-XSS-Protection">X-XSS-Protection</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
ブラウザがXSS攻撃を検出した時にページの読み込みを自動で停止します。
CSPが厳しく設定済みであれば、このヘッダーは本来不要です。 
しかし、ユーザーがCSPに未対応の古いブラウザ（IE9以下）を利用している場合に有効な対策になります。
<h2 id="Strict-Transport-Security">Strict-Transport-Security</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security" target="_blank">Strict-Transport-Security - HTTP | MDN</a>
HTTPS でページにアクセスした時にHTTPレスポンスヘッダーに含めることで、次回以降はブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示する事ができます。
初めてのユーザーが HTTP でページにアクセスした場合は Strict-Transport-Security 無視されるため、ユーザーが HTTPS アクセスを一度もしていない場合には有効でない事に注意してください。 
HTTPS アクセスをしてSSL証明書が確認されたタイミングで設定が有効になります。
<pre><code># HTTPSアクセスの設定を1年間有効にする（有効期限はアクセスの度に更新される）
Strict-Transport-Security: max-age=31536000;
</code></pre>
<h3 id="脆弱性の説明">脆弱性の説明</h3>
HTTPアクセスが許可されている銀行サイトを普段から利用していたとします。 
カフェで無料のWifiに接続した状態で、その銀行サイトをHTTP経由で利用をしてしまった場合に、攻撃者にHTTPリクエストの内容を傍受され銀行口座やログイン情報などが盗まれる可能性があります。
<h3 id="対策方法">対策方法</h3>
Strict-Transport-Security ヘッダーを指定する。
上の例では、もし銀行サイトが Security-Transport-Security を設定しており、一度でも HTTPS で銀行サイトにアクセスしていた場合には、誤ってHTTPアクスした場合でも HTTPS 経由で自動で接続されるため被害を防ぐことができます。

WebセキュリティのためのHTTPレスポンスヘッダー

<h2 id="インストール">インストール</h2>
<a href="https://github.com/denoland/deno" target="_blank">denoland/deno: A secure JavaScript and TypeScript runtime</a>
<pre class="language-shell"><code class="language-shell">$ curl -fsSL https://deno.land/x/install/install.sh | sh
$ vi ~/.zshrc
# Denoのパス設定
export DENO_INSTALL="/Users/t-yng/.local"
export PATH="$DENO_INSTALL/bin:$PATH"

$ source ~/.zshrc
</code></pre>
インストール直後はパスが通っていない状態なので ~/.zshrc にDenoのパス設定を追加して再読み込みします。 
※ 個人の環境に合わせて適宜読み替えてください
HomeblewやCargoを利用してもインストールできます。 
詳細は <a href="https://deno.land/" target="_blank">https://deno.land/</a> を確認してください。
<h2 id="VsCodeの拡張">VsCodeの拡張</h2>
今の状態でVSCodeでコードを書くとTypeScriptとして認識されるので、Denoの構文でエラーが発生します。 
そこで <a href="https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno" target="_blank">Deno - Visual Studio Marketplace</a> をインストールしておきます。
デフォルトでは設定が false になっているので .vscode/setting.json で拡張を有効化します。 
自分は Node.js 環境で TypeScript を書く場合に競合する事を避けるために、プロジェクト単位で有効化しています。
<pre class="language-json"><code class="language-json">{
 "deno.enable": true
}
</code></pre>
<h2 id="Hello World を表示する">Hello World を表示する</h2>
最初に「Hello World」を表示するサンプルコードを実装してみます。
<pre class="language-shell"><code class="language-shell">$ mkdir deno-sample
$ cd deno-sample
$ touch server.ts
</code></pre>
<h3 id="server.ts">server.ts</h3>
deno-sample/server.ts に次のサンプルコードを記述します。
<pre class="language-typescript"><code class="language-typescript">import { serve } from "https://deno.land/std@v0.39.0/http/server.ts";

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000/");

for await (const req of s) {
 req.respond({ body: "Hello World\n" });
}
</code></pre>
最初のimport文はモジュール読み込みです。 
Denoは npm を利用せずにURLやファイルパスでモジュールを読み込む仕組みになっており、サンプルコードでは deno.land にホスティングされた標準APIのモジュールを読み込んでいます。
次に <code>serve({port: 8000})</code> でサーバーインスタンスを生成しています。
ここで生成されるサーバーインスタンスはPromiseのイテレーターとなっているので、 <code>for await</code> でループ処理にてリクエストのインスタンスを取得して、 Hello World の文字列をレスポンスとして返しています。
<h3 id="実行">実行</h3>
エラーが発生しました。
<pre class="language-shell"><code class="language-shell">$ deno server.ts

Compile file:///Users/xxxxxx/workspace/deno/deno-sample/server.ts
error: Uncaught PermissionDenied: network access to "127.0.0.1:8000", run again with the --allow-net flag
</code></pre>
Denoではネットワークアクセスやファイルアクセスには許可が必要なため、今回はネットワークアクセスを許可するために <code>--allow-net</code> フラグを指定します。
<pre><code>$ deno --allow-net server.ts
access to http://localhost:8000/
</code></pre>
今度は成功しました。 
この状態で http://localhost:8000/ にアクセスすれば、「Hello World」がブラウザに表示されます。🎉
<h2 id="HTMLを返す">HTMLを返す</h2>
次にHTMLを返すWebサーバーを実装してみます。
<h3 id="ディレクトリ構造">ディレクトリ構造</h3>
public/index.html は適当に作成してください。
<pre><code>.
├── public
│   └── index.html
└── server.ts
</code></pre>
<h3 id="server.ts">server.ts</h3>
fs モジュールの <code>readFileStr</code> でHTMLファイルの文字列を読み込みをしています。
正しく実装するなら、<a href="https://deno.land/std/manual.md#file-server" target="_blank">File Server</a>として実装した方が良さそうですが、ファイル読み込みをを試してみたかったので、この書き方をしています。
<pre class="language-typescript"><code class="language-typescript">import { serve } from "https://deno.land/std/http/server.ts";
import { readFileStr } from "https://deno.land/std/fs/mod.ts";

// HTMLファイルを読み込んで文字列を取得
const html = await readFileStr("./public/index.html", {
 encoding: "utf8",
}).catch((error) => {
 console.log(error);
 return "読み込みに失敗したよ";
});

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000");
for await (const req of s) {
 req.respond({ body: html }); // HTML文字列をレスポンスBodyにセット
}
</code></pre>
<h3 id="実行">実行</h3>
ファイル読み込みをしているので <code>--allow-read</code> フラグを新たに指定しています。
<pre class="language-shell"><code class="language-shell">$ deno --allow-net --allow-read server.ts
access to http://localhost:8000/
</code></pre>
<h2 id="パッケージ管理">パッケージ管理</h2>
<h3 id="問題">問題</h3>
現状では npm のようなパッケージ管理ツールがなく、ソース単位で外部モジュールの読み込みを書いている状態です。 
依存している外部ライブラリを把握するためには、ソースコードを全て見る必要があり管理が困難になってしまいます。
<h3 id="deps.ts">deps.ts</h3>
deps.ts ファイルを新しく作り、モジュール読み込みの記述をまとめることで簡易的なパッケージ管理が実現できます。 
deps.ts はマニュアルで紹介されいているファイル名で名前は何でもOKです。 
ライブラリを見ていると、deps.ts か package.ts をファイル名として利用しているパターンが多かったです。
先ほどのHTMLを返すサンプルコードの一部を deps.ts を利用して書き直してみるとこんな感じです。
deps.ts
<pre class="language-typescript"><code class="language-typescript">export { serve } from "https://deno.land/std/http/server.ts";
export { readFileStr } from "https://deno.land/std/fs/mod.ts";
</code></pre>
server.ts
<pre class="language-typescript"><code class="language-typescript">import { serve, readFileStr } from "./deps.ts";

// 後は同じ
...
</code></pre>
<h2 id="ドキュメント">ドキュメント</h2>
<ul>
<li><a href="https://deno.land/" target="_blank">Dono 公式ドキュメント</a></li>
<li><a href="https://deno.land/typedoc/" target="_blank">API Reference</a></li>
</ul>

Denoを触ってみよう

GitHubのリポジトリ内の特定のディレクトリだけをローカルにダウンロードした場合 
https://github.com/zeit/next.js/tree/canary/examples/analyze-bundles
svnを利用して <code>svn export &lt;リポジトリのURL&gt;/trunk/&lt;ディレクトリのパス&gt;</code> とする事で簡単にダウンロードできます。
<pre class="language-shell"><code class="language-shell">$ svn export https://github.com/zeit/next.js/trunk/examples/analyze-bundles
</code></pre>
MacOSであればsvnは標準でインストールされているので手軽にダウンロードができて便利です。

GitHubのディレクトリをCLIでダウンロード

とあるフロントエンドエンジニアのブログ

記事一覧