ブラウザからcookieを制御できないときに確認すべき3つのこと

今回のケースでは、自身が管理するドメインに対するcookieを話題としている。
もし異なるドメインに対するcookieやhttpレスポンスについて興味がある場合は、CORSも参照のこと。

Httponly属性がついていないか

この属性がついているcookieは、javascriptで操作できない。

“クッキーの紹介の中で、クッキーをJavaScriptから触ることができることを紹介したが、この属性を付けるとJavaScriptエンジンから、クッキーを隠すことができる。クロスサイトスクリプティングなど、悪意のあるJavaScriptが実行されるセキュリティリスクに対する防護となる”

抜粋:: 渋川　よしき “Real World HTTP”。 ::

Domain属性が指定されていないか

この属性がついているcookieは、そのドメインおよびサブドメインが送信対象のサーバとしてブラウザに認識される(.exampl.comというように頭に.がつく)。このcookieを操作する際には次のようにdomainオプションを明示的に指定する必要がある[^1]。

```javascript:クッキーを削除する`
document.cookie=“Key=;max-age=0;domain=.example.com”

[^1]: 指定しないと、暗黙に`example.com`が指定されることになる。


Domain属性の有無による挙動の違いについてはこちらを参照 
[CookieのDomain属性は *指定しない* が一番安全
 徳丸浩の日記](https://blog.tokumaru.org/2011/10/cookiedomain.html)
[ HTTP State Management Mechanism RFC6265 4-1-2](https://tools.ietf.org/html/rfc6265#section-4.1.2)

## Secure属性がついていないか
この属性が付いている`cookie`は、http接続の場合はサーバに送信されない。

“https接続での安全な接続時以外は、クライアントからサーバーへのクッキー送信をしない。クッキーはURLをキーとして送受信するかどうかを決めており、これにはDNSのハッキングによってURLが詐称されることで利用者が意図しないサーバーにクッキーを送信してしまうリスクがある。DNSのハッキングは、マシンを操作しなくても無料のWifiサービスなどを詐称するなどの方法で簡単に実行できる。Secure属性をつけることで、http接続が使われる時にはブラウザが警告を出し、ページヘのアクセスを止めるため、流出を防げるようになる”

抜粋:: 渋川　よしき  “Real World HTTP”。 ::