original: Robustness principle
コンピューティングの世界において、堅牢性原則はソフトウェア設計のガイドラインである：
あなたが為すべきことには保守的であれ、あなたが他から受け入れることには寛容であれ（しばしば「あなたが送るものには保守的であれ、あなたが受け取るものには寛容であれ」と言い換えられる）
この原則は、TCPの初期の仕様を執筆したジョン・ポステルに因んで、ポステルの法則としても知られている：
TCPの実装は一般的な堅牢性原則に則ること。つまり、あなたが為すべきことには保守的であれ、あなたが他から受け入れることには寛容であれ、である。
換言しよう。他の機器（または同じ機器内の別のプログラム）にメッセージを送るプログラムは、仕様に完全に従うべきだが、メッセージを受け取るプログラムは、意味が明らかである限りは適合していない入力も受け取るべき、ということだ。
プログラマーの間では、互換性のある機能を作るために、この原則は入力の反変性と出力の共変性の形式としても知られている。
RFC 1122 (1989)は、プログラマーが「ネットワークは、能う限り最悪の影響を及ぼすパケットを送りつける、悪意のあるエンティティで満ちていると仮定する」ことを推奨することによってポステルの法則を拡大した。プロトコルは、未知の符号を含んだメッセージを受け入れる（できればログは取っておく）ことで、将来のバージョンで既存のフィールドに新しい符号を追加するのを許可すべきである。プログラマーは、受信者に欠陥を晒すことになるかもしれない「合法だが曖昧なプロトコルの特徴」を持つメッセージを送らないようにすべきであり、「行儀の悪いホストで生き延びるだけでなく、このようなホストが共有のコミュニケーション設備に対して引き起こす混乱の量を制限するよう協力する」コードを設計すべきである。
2001年、マーシャル・ローズはポステルの原則を新しいアプリケーションのプロトコルの設計に適応する際に、いくつかデプロイ上の問題を特徴づけた。例えば、適合していないメッセージを送信する欠陥のある実装は、それが何年も後かもしれないが、そんなメッセージを拒絶する寛容さの少ないアプリケーションと接続されるまで、仕様との差を許容する実装相手にしか使われないかもしれない。このような状況では、問題の特定はしばしば難しく、また解決策をデプロイするのにコストが掛かりうる。それゆえローズは「例え実装のオーバーヘッドを強いることになったとしても、プロトコルにおける明確な一貫性のチェック」を推奨した。
2015年から2018年、一連のインターネット・ドラフトにおいて、ポステルの堅牢性原則は実際のところセキュリティを含む堅牢性の欠如をもたらしたと、マーティン・トムソンは主張した：
欠陥はデファクト・スタンダードとして固着してしまうだろう。プロトコルの如何なる実装も、異常な動作を複製するか、あるいは相互運用できないものとなる。これは堅牢性原則を適用した結果であり、致命的なエラー状態を避けるのを嫌がった結果でもある。この環境における相互運用性の確保は、「バグと互換性のあるバグ」であろうとしている、としばしば言われたりする。
2018年、ポステルの堅牢性原則を悪用して、Torのルーティング・プロトコルの内部でオニオンサービスとTorクライアントの匿名性をどのように損なわせたかを、フロランタン・ロシェとオリヴィエ・ペレイラによるプライバシー強化技術（PET）についての論文が示した。