経験豊富なプログラマーのための序文
スレッド-フラスコのローカル
Flaskでの設計上の決定の1つは、単純なタスクは単純でなければならないということでした。 彼らは多くのコードを取るべきではありませんが、それでも彼らはあなたを制限するべきではありません。 そのため、Flaskには、意外な、または非正統的なデザインの選択肢がいくつかあります。 たとえば、Flaskは内部でスレッドローカルオブジェクトを使用するため、スレッドセーフを維持するためにリクエスト内で関数間でオブジェクトを渡す必要はありません。 このアプローチは便利ですが、依存性注入のため、または要求にペグされた値を使用するコードを再利用しようとする場合は、有効な要求コンテキストが必要です。 Flaskプロジェクトは、スレッドローカルについて正直であり、それらを非表示にせず、それらが使用されるコードとドキュメントで呼び出します。
注意してWeb用に開発する
Webアプリケーションを構築するときは、常にセキュリティを念頭に置いてください。
Webアプリケーションを作成する場合は、ユーザーがサーバーにデータを登録して残すことを許可している可能性があります。 ユーザーはあなたにデータを委託しています。 また、アプリケーションにデータを残す可能性のある唯一のユーザーであっても、そのデータを安全に保存する必要があります。
残念ながら、Webアプリケーションのセキュリティが危険にさらされる可能性のある方法はたくさんあります。 Flaskは、最新のWebアプリケーションの最も一般的なセキュリティ問題の1つであるクロスサイトスクリプティング（XSS）からユーザーを保護します。 安全でないHTMLを意図的に安全としてマークしない限り、Flaskと基盤となるJinja2テンプレートエンジンで対応できます。 しかし、セキュリティの問題を引き起こす方法は他にもたくさんあります。
ドキュメントは、セキュリティに注意を払う必要があるWeb開発の側面について警告します。 これらのセキュリティ上の懸念のいくつかは、想像以上に複雑であり、巧妙な攻撃者がアプリケーションを悪用する方法を見つけるまで、脆弱性が悪用される可能性を過小評価することがあります。 また、アプリケーションが攻撃者を引き付けるほど重要でないとは思わないでください。 攻撃の種類によっては、自動化されたボットがデータベースをスパムや悪意のあるソフトウェアへのリンクなどで埋める方法を調査している可能性があります。
Flaskは、開発者が要件に合わせてビルドするときにエクスプロイトに注意してビルドする必要があるという点で、他のフレームワークと同じです。
