安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scri
型チェックは TypeScript や Flow じゃなくて JavaScript にやらせる。 - Qiita
開発効率のために型チェックを望む JavaScript が動的型言語なので、静的型言語にしてしまえば開発効率があがる、というアイデアがあって、それは確かなことかとも思います。プログラムを書いていて、ある変数の型がよくわからなければ正確な処理を行わせるのって、難しいですよね。 確かに開発効率、あがると思います。 実際に自分も開発効率をあげています。しかし、型チェックは行っていますが、TypeScript や Flow とかは使っていません。 TypeScript や Flow が人気を得てきていますが、そこで行う型チェックは、素のJavaScriptにやらせてしまうこともできるので、導入前に検討してみるのもよいかもしれません。 チーム開発の場合には、型チェックを自前で行わないエンジニアにも型チェックを行ってもらうという意味で、TypeScript 等を導入する価値はたしかに大きくあると思いま
漸進的型付けの未来を考える - -
この記事はCAMPHOR- Advent Calendar 2017 11日目の記事です． アブストラクト 漸進的型付けは，ひとつの言語の中で静的型付けと動的型付けをスムーズに組み合わせるための技術です． よく知られた特徴は any 型を使った静的型付けで， TypeScript や Python といったプログラミング言語には既に実装されています． しかし，理論と実際のプログラミング言語の間には大きなギャップが存在します． 特に，漸進的型付けの理論で提案されているキャストを用いた動的型検査が実装されていないために， 静的型付けの恩恵を十分に得られていないという問題があります． この記事では，まず漸進的型付けの理論をコード例を用いて紹介し， 現状の漸進的型付き言語が抱える問題を解説します． そのあとで，漸進的型付き言語が目指すべき目標を理論的視点から論じます． それらの目標は，静的型付けを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kaist-plrg/jstar: JSTAR: JavaScript Specification Type Analyzer using Refinement
