クロスサイトスクリプティング攻撃からウェブサイトを保護する別の方法は、ページ内でユーザーによる入力を、直接にはまったく使わないようにすることだ。ユーザー入力では、それぞれが「鍵」として使われる限られた数の値を受け入れることによって、あらかじめ定義した一定のオプションの中から選択させる。これは、ユーザーによる入力を使用して出力を定義できる方法の1つの例だが、明らかに、ウェブアプリケーションの動的な性質は大幅に制限される。しかしウェブサイトで、この対策を採用した場合に得られるより高い自由度が必要でなければ、これが、ユーザー入力に基づいて出力を生成する場合に最も安全なオプションになるだろう。
同様に、特定の、限定した入力型に関して承認されていない文字はすべて単純に削除する（電話番号を格納することになっている入力からは、ダッシュ、丸かっこ、ピリオド、数字以外の文字はすべて削除するなどの）入力検証や、承認されていない文字が入力に含まれる場合はその全体を拒否する入力検証を利用できる。これは多くの入力フォームで有効な技法だが、すべてのフォームに役立つわけではない。こうした検証技法は、クロスサイトスクリプティングからの保護だけでなく、システムの境界を越えようとするバッファオーバーフロー、SQLインジェクションなどの試みにより、サーバ自体を直接侵害しようとする攻撃からの保護にもなるため、可能な場合には常に使用する必要がある。
Cookieは、クロスサイトスクリプティングに対してある種のセキュリティを提供するためによく使用される。クロスサイトスクリプティングの多くの攻撃は、セッションCookieを盗むように設計されているが、乗っ取られたCookieがクロスサイトスクリプティング攻撃に使われるときに検証に失敗するように、Cookieを特定のIPアドレスに結び付けることができる。もちろん、この種のセキュリティには、Cookieの正当なユーザーと、クロスサイトスクリプティング攻撃の両方が同じプロキシサーバやNATデバイスの背後からアクセスする状況を作るなど、可能な回避策が存在する。Internet Explorerには、こうしたCookieの悪用からの保護を目的として、ローカルスクリプトがCookieに影響を与えないようにするHTTPOnlyフラグが実装されているが、サーバでの要求の認証に使われるCookieと一緒に、クロスサイトスクリプティング攻撃によって意図しない要求が送信されることがあるクロスサイト要求の偽造攻撃には無力なのだ。
ただし、ウェブ開発においてクロスサイトスクリプティングを回避する最も有効な単独の手段は、クライアント側のコードを一切必要としないようにウェブサイトを設計することだ。そうすればユーザーは、自分のブラウザでJavaScriptインタープリタをオフにしたければ、ウェブサイトを利用するための機能を失うことなくオフにできる。もちろんこの方法では、サーバに悪意のある入力を行うおそれがあるあらゆる形態に関して保護が行われるわけではなく、すべて単独で実際にウェブサイトの脆弱性を抑えるわけでもない。しかし、ウェブサイトを訪問するユーザーに、自分を保護するためのオプションを提供することになるのは確かなのだ。
