"複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理部と、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理部の動作を制御する制御部とを備える情報処理装置。上記処理部は、ウェブブラウザであり、上記処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトである請求項1に記載の情報処理装置。上記セキュリティ制約は、上記オブジェクト内へのスクリプトの挿入権限である請求項2に記載の情報処理装置。上記セキュリティ制約は、上記オブジェクト内のスクリプトの実行可能権限である請求項2に記載の情報処理装置。上記セキュリティ制約は、リクエストに関する制限である請求項2に記載の情報処理装置。上記セキュリティ制約は、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である請求項2に記載の情報処理装置。上記セキュリティ制約は、アプリケーションプログラミングインタフェースへのアクセス権限である請求項2に記載の情報処理装置。上記セキュリティ制約は、異なる生成元からのオブジェクトの参照あるいは変更のリクエストのポリシー変更である請求項2に記載の情報処理装置。上記セキュリティ制約は、子オブジェクトも含めたヒープ使用量の上限である請求項2に記載の情報処理装置。上記セキュリティ制約は、子オブジェクトも含めたオブジェクト数の上限である請求項2に記載の情報処理装置。上記セキュリティ制約は、上記オブジェクトに設定できる文字列長の上限である請求項2に記載の情報処理装置。上記セキュリティ制約は、上記オブジェクトに属性として与えられる請求項2に記載の情報処理装置。上記セキュリティ制約は、クラスで指定される請求項12に記載の情報処理装置。上記セキュリティ制約は、セキュリティオブジェクトにより定義される請求項2に記載の情報処理装置。上記セキュリティ制約の指定のないオブジェクトのセキュリティ制約として、親からのセキュリティ制約を引き継ぐ請求項2に記載の情報処理装置。所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、該所定のオブジェクトのセキュリティ制約を引き継ぐ請求項2に記載の情報処理装置。HTTPヘッダにより上記セキュリティ制約を指定する請求項2に記載の情報処理装置。上記セキュリティ制約は、所定の条件に応じて動的に変化する請求項2に記載の情報処理装置。複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理ステップと、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理ステップ得の動作を制御する制御ステップとを備える情報処理方法。コンピュータを、複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理手段と、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理手段の動作を制御する制御手段として機能させるプログラム。しかし、プログラムをどれだけ検証しても、現実にはバグが発見され脆弱性が露呈することが後を絶たない。また、ウェブアプリケーションは年々規模を拡大し複雑化していることから、バグの発見はより困難になると予想される。そのことを踏まえると、ウェブアプリケーションにはバグが必ずある前提で、ウェブブラウザがそのバグから利用者を守る必要がある。しかし、従来の技術ではそれに該当するものはなかった。本技術の目的は、ウェブアプリケーション上の脆弱性などを良好に防止可能とすることにある。本技術の概念は、複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理部と、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理部の動作を制御する制御部とを備える情報処理装置にある。処理部により、複数の処理データから選択された所定の処理データに基づいて情報処理が行われる。制御部により、処理部の動作が制御される。この場合、所定の処理データに関連付けされたセキュリティ制約に基づいて、制御が行われる。ここで、例えば、処理部はウェブブラウザであり、処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトであってもよい。本技術においては、ウェブアプリケーション上の脆弱性などを良好に防止できる。例えば、セキュリティ制約は、オブジェクト内へのスクリプトの挿入権限であってもよい。また、例えば、セキュリティ制約は、オブジェクト内のスクリプトの実行可能権限であってもよい。また、例えば、セキュリティ制約は、リクエストに関する制限であってもよい。また、例えば、セキュリティ制約は、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定であってもよい。また、例えば、セキュリティ制約は、アプリケーションプログラミングインタフェースへのアクセス権限であってもよい。また、例えば、セキュリティ制約は、異なる生成元からのオブジェクトの参照あるいは変更のリクエストのポリシー変更であってもよい。また、例えば、セキュリティ制約は、子オブジェクトも含めたヒープ使用量の上限であってもよい。また、例えば、セキュリティ制約は、子オブジェクトも含めたオブジェクト数の上限であってもよい。また、例えば、セキュリティ制約は、オブジェクトに設定できる文字列長の上限であってもよい。例えば、セキュリティ制約は、オブジェクトに属性として与えられてもよい。その場合、セキュリティ制約は、クラスで指定されてもよい。また、例えば、セキュリティ制約は、セキュリティオブジェクトにより定義されてもよい。また、例えば、セキュリティ制約の指定のないオブジェクトのセキュリティ制約として、親からのセキュリティ制約を引き継ぐようにされてもよい。また、例えば、所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、この所定のオブジェクトのセキュリティ制約を引き継ぐようにされてもよい。また、例えば、HTTPヘッダによりセキュリティ制約を指定するようにされてもよい。また、例えば、セキュリティ制約は、所定の条件に応じて動的に変化するようにされてもよい。本技術によれば、ウェブアプリケーション上の脆弱性などを良好に防止できる。以下、発明を実施するための形態以下、実施の形態とするについて説明する。なお、説明を以下の順序で行う。1.実施の形態2.変形例<1.実施の形態>[ウェブシステム]図1は、実施の形態としてのウェブシステム100の構成例を示している。このウェブシステム100は、ウェブブラウザを含むクライアント装置110と、サーバ装置120a,120Bとが、ネットワーク130を介して接続されて構成されている。クラインアント装置110とサーバ装置120A,120Bとは互いに通信を行う。このウェブシステム100は、一般的なネットワークレベルでは既存のシステムと異なる点はない。ウェブブラウザは、サーバ装置120Aからページを読込み、表示する。その際に、他のサーバ装置120Bからリソースを取得することも含む。また、ウェブブラウザは、表示した後もスクリプトによって継続してサーバ装置120A,120Bとのアクセスが発生するシステムも含む。図2は、ウェブブラウザの構成例を示している。ウェブブラウザは、画面やスクリプト等のオブジェクトから構成されるドキュメントオブジェクトモデルDOM:DocumentObjectModelと、スクリプトエンジンからなる。ウェブブラウザは、ページや画像をロードする。また、ウェブブラウザは、スクリプトから呼ばれるアプリケーションプログラミングインタフェースAPI:ApplicationProgrammingInterfaceにより、サーバ装置へリクエストを出し、サーバ装置からレスポンスを受け取る。この実施の形態では、DOMの各オブジェクトにセキュリティ制約が与えられる。そして、スクリプトエンジンがスクリプトを実行する際に、その制約を満たしているかが検証され、満たしていない場合に、特殊な動作に移行するようにされる。図3のフローチャートは、スクリプトエンジンの処理の流れの一例を概略的に示している。スクリプトエンジンは、ステップST1において、処理を開始する。そして、スクリプトエンジンは、ステップST2において、スクリプトの実行が指示されたか否かを判断する。スクリプトの実行が指示されたとき、スクリプトエンジンは、ステップST3において、セキュリティ制約を満たしているか否かを判断する。セキュリティ制約を満たしているとき、スクリプトエンジンは、ステップST4において、スクリプトを実行する。スクリプトエンジンは、このステップST4の処理の後、ステップST5において、処理を終了する。一方、ステップST3でセキュリティ制約を満たしていないとき、スクリプトエンジンは、ステップST6において、スクリプトを実行する代わりに、特殊な動作、例えば、エラー箇所やその原因を示すエラーダイアログを出す等する。スクリプトエンジンは、このステップST6の処理の後、ステップST5におおいて、処理を終了する。次に、セキュリティ制約、セキュリティ制約の指定方法、ウェブブラウザの動作などを具体的に説明していく。[セキュリティ制約]DOMのオブジェクトに与えられるセキュリティ制約として、例えば、以下が挙げられる。1オブジェクト内へのスクリプトの挿入権限DOMのオブジェクトに与えられるセキュリティ制約を、オブジェクト内へのスクリプトの挿入権限とすることができる。この場合、例えば、攻撃スクリプトを含んだ投稿などのオブジェクトへの挿入を防止できる。図4は、DOMのオブジェクトに与えられるセキュリティ制約がオブジェクト内へのスクリプトの挿入権限である場合について示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。1アタッカattackerは、サーバに、攻撃スクリプトを含んだ投稿を送る。2クライアントclientは、サーバserverから、この攻撃スクリプトを含んだ投稿を受信する。3クライアントでは、この攻撃スクリプトを含んだ投稿がDOM上に配置される。4そして、この攻撃スクリプトが実行される。DOMのオブジェクトに、セキュリティ制約として、オブジェクト内へのスクリプトの挿入権限が与えられる場合には、挿入されるdiv要素にスクリプトの挿入権限が無ければ、上述の3の段階で攻撃スクリプトの挿入を防止でき、攻撃スクリプトの実行を阻止できる。2オブジェクト内のスクリプトの実行可能権限DOMのオブジェクトに与えられるセキュリティ制約を、オブジェクト内のスクリプトの実行可能権限とすることができる。この場合、例えば、攻撃スクリプトの実行を阻止できる。図5は、DOMのオブジェクトに与えられるセキュリティ制約がオブジェクト内のスクリプトの実行可能権限である場合について示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。1アタッカattackerは、サーバに、攻撃スクリプトを含んだ投稿を送る。2クライアントclientは、サーバserverから、この攻撃スクリプトを含んだ投稿を受信し、表示する。3攻撃スクリプトが、実行される。DOMのオブジェクトに、セキュリティ制約として、オブジェクト内のスクリプトの実行可能権限が与えられる場合には、挿入されるdiv要素にスクリプトの実行可能権限が無ければ、上述の3の段階における攻撃スクリプトの実行を阻止できる。図6も、DOMのオブジェクトに与えられるセキュリティ制約がオブジェクト内のスクリプトの実行可能権限である場合について示している。この場合は、スクリプトを介してdiv要素が操作される場合を示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。1アタッカattackerは、サーバに、攻撃スクリプトを含んだ投稿を送る。2クライアントclientは、サーバserverから、この攻撃スクリプトを含んだ投稿を受信する。3クライアントにおいて、攻撃スクリプトを含んだ投稿がDOM上に配置される。4そして、攻撃スクリプトが、実行される。DOMのオブジェクトに、セキュリティ制約として、オブジェクト内のスクリプトの実行可能権限が与えられる場合には、挿入されるdiv要素にスクリプトの実行可能権限が無ければ、上述の4の段階における攻撃スクリプトの実行を阻止できる。3リクエスト制限DOMのオブジェクトに与えられるセキュリティ制約を、リクエストに関する制限クッキーcookie等の情報の送出許可とすることができる。この場合、例えば、攻撃リンクからサーバへのクッキーcookie付きのリクエストの送信を防止できる。図7は、DOMのオブジェクトに与えられるセキュリティ制約がリクエストに関する制限である場合について示している。ここでは、認証が必要なメールMailやソーシャルネットワーキングサービスSNS:SocialNetworkServiceを想定している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。1アタッカattackerは、サーバに、攻撃リンクを含んだ投稿を送る。2クライアントclientは、サーバserverから、この攻撃リンクを含んだ投稿を受信し、攻撃リンクも表示する。3クライアントにおいて、攻撃リンクをユーザが踏むと、4クライアントからサーバにリクエストが飛ぶ。このとき、クライアントはサーバにクッキーcookieも送る。そのため、クライアントのユーザの権限でサーバの状態を変更できる投稿や削除、設定変更が可能。DOMのオブジェクトに、セキュリティ制約として、リクエストに関する制限が与えられる場合には、投稿が表示されるdiv要素にクッキーcookieを送る権限が無ければ、攻撃リンクを何の効力も持たないものとできる。4スクリプトのアクセス可能/不可能オブジェクトの指定DOMのオブジェクトに与えられるセキュリティ制約を、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定とすることができる。この場合、例えば、攻撃スクリプトがクッキーcookieを取得することを阻止でき、また、例えば、攻撃スクリプトが取得した情報をAPIで攻撃者のサーバに送信することを阻止できる。図8は、DOMのオブジェクトに与えられるセキュリティ制約がスクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である場合について示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。1クライアントclientは、サーバserverから、コンテンツを読み込む。2外部サーバhackedserverがハックhackされ、攻撃スクリプトを含んだライブラリに差し替えられ、それがクライアントに読み込まれる。3クライアントにおいて、攻撃スクリプトが実行され、攻撃スクリプトはセッション情報や個人情報を取得する。4そして、攻撃スクリプトは、取得した情報を攻撃者のサーバattackerseverに送る。DOMのオブジェクトに、セキュリティ制約として、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定が与えられる場合には、クッキーcookie等へのアクセス権限が制限されていれば、攻撃スクリプトによる、クッキーcookie等の取得を阻止できる。また、この場合には、使用可能なAPIが制限されていれば、攻撃スクリプトが、攻撃者のサーバへ取得した情報を送信すること阻止できる。5その他のセキュリティ制約DOMのオブジェクトに与えられるセキュリティ制約を、APIへのアクセス権限とすることができる。ただし、APIもオブジェクトとして定義される場合は、上述の4スクリプトのアクセス可能/不可能オブジェクトの指定の項目と等価となる。また、DOMのオブジェクトに与えられるセキュリティ制約を、SOPSameOriginPolicyやCORSCrossOriginResourceSharing等のリクエストのポリシーの変更とすることができる。ここで、SOPとは、異なる生成元からのオブジェクトの参照や変更を禁止する仕組みであり、CORSとは、異なる生成元からオブジェクトの参照や変更を可能にする仕組みである。また、DOMのオブジェクトに与えられるセキュリティ制約を、子オブジェクトも含めたヒープ使用量の上限とすることができる。また、DOMのオブジェクトに与えられるセキュリティ制約を、子オブジェクトも含めたオブジェクト数の上限とすることができる。さらに、DOMのオブジェクトに与えられるセキュリティ制約を、オブジェクトの各アトリビュート等に設定できる文字列長の上限とすることができる。また、XHRXMLHttpRequest以外にも、imgやiframe等による外部へのリクエスト先のドメインやポートで制約することもできる。[セキュリティ制約の指定方法]次に、セキュリティ制約の指定方法書き方について説明する。1各オブジェクトに属性として与えるセキュリティ制約を、各オブジェクトに属性として与えることができる。図9は、その場合における、セキュリティ制約の書き方例例1を示している。図10も、その場合におけるセキュリティ制約の書き方例例2を示している。図9の例の場合には、要素にセキュリティ制約を直接指定するが、図10の例の場合には、要素にセキュリティクラスを指定し、セキュリティ制約を間接的に指定する。図10の例の場合、図11に示すように、DOM上にセキュリティクラスを定義するオブジェクトが設けられることになる。2セキュリティオブジェクトによる定義各オブジェクトのセキュリティ制約を、セキュリティオブジェクトにより定義することができる。この場合、HTMLの中にセキュリティ制約を列挙したオブジェクトが定義され、オブジェクト生成時にどのようなセキュリティ制約を与えるかが決定される。3HTTPヘッダによる指定各オブジェクトのセキュリティ制約を、HTTPヘッダで指定することができる。この場合、セキュリティオブジェクトの定義を書くことができる。あるいは、ヘッダでのみスクリプトを実行可能といった簡易的な指定を行うことができる。図12は、その場合におけるセキュリティ制約の書き方例例3を示している。この場合、ヘッダheadタグのみでのスクリプトscriptの実行を許可する。1行で指定するため、複雑な指定はできない。フォームFormの中でのスクリプトscriptの実行禁止など、攻撃の対象となる場所をピンポイントに潰す指定が主になる。4親からのセキュリティ制約の引き継ぎセキュリティ制約の指定のないオブジェクトのセキュリティ制約を、親のセキュリティ制約を引き継ぐようにすることもできる。このように親からのセキュリティ制約の指定を引き継ぐことで、効率的なセキュリティ制約の指定が可能となる。例えば、親オブジェクトのセキュリティがAクラスに指定され、第1の子オブジェクトのセキュリティが指定されておらず、第2の子オブジェクトのセキュリティがBクラスに指定されているとする。この場合、第1の子オブジェクトには、親オブジェクトのセキュリティであるAクラスが引き継がれることとなる。5呼び戻し元のセキュリティ制約の引き継ぎ所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、この所定のオブジェクトのセキュリティ制約を引き継ぐようにすることもできる。自分固有のセキュリティ制約を持たないオブジェクトへのアクセスのラッパーなどの機能を持つライブラリ等で用いることができる。なお、上述したようにセキュリティ制約の定義をHTMLに書いてもよいが、外部ファイルによって定義することもできる。その場合、HTMLには、外部ファイルを参照することが記載される。[ウェブブラウザの動作]1スクリプト実行時に、DOM上のオブジェクトに対するアクセスが発生した場合には、以下の動作をする。すなわち、実行中のコンテキストのセキュリティ制約から、対象のオブジェクトへのアクセス権限があるかを確認する。そして、アクセス権限がある場合には実行を続けるが、無い場合には処理を中断して例外を発生させる。この場合、スクリプトエンジンは例外ハンドラを読み出し、また、エラー個所や原因を示すエラーダイアログを出して停止する。2リンククリックやスクリプトなどによってネットワークに対するリクエストが発生した場合、以下の動作をする。すなわち、実行中のコンテキストのセキュリティ制約から、対象ドメインやポートへのアクセス権限があるかを確認する。そして、リンクをクリックした場合は、そのリンクが属するセキュリティ制約に従ってリクエスト権限があるかを確認する。そして、リクエスト権限がある場合には実行を続けるが、無い場合には処理を中断して例外を発生させる。3異なったセキュリティ制約を持つ関数オブジェクトを呼び出す場合、現在のセキュリティ制約をスタックに積み、飛び先の関数オブジェクトのセキュリティ制約をコンテキストに設定する。そして、異なったセキュリティ制約を持つ関数オブジェクトから戻る場合、上述のスタックからセキュリティ制約をポップして、それをコンテキストに設定する。4オブジェクトのプロパティを書き換える場合、現在のセキュリティ制約に従い、文字数などの制約を超えないことを確認する。上述したように、図1に示すウェブシステム100においては、DOM上のオブジェクトに対して適切なセキュリティ制約が設定されることにより、バグが発見されても、XSSやCSRF、あるいは未知の脆弱性を防ぐことができる。また、図1に示すウェブシステム100においては、DOM上のオブジェクトに対して適切なセキュリティ制約が設定されることにより、外部サーバ上のスクリプトを安全に利用することができる。仮に、中に悪意のあるスクリプトが混ざっていても、このスクリプタは、重要な情報を取得できず、被害を最小限に留めることができる。また、図1に示すウェブシステム100においては、DOM上のオブジェクトに対して適切なセキュリティ制約が設定されることにより、ウェブブラウザ自体のバグ等によるUXSS等の未知の脆弱性も防ぐことができる。また、図1に示すウェブシステム100においては、一部のスクリプトに対して制限をかけると同時に同一生成元ポリシーを変更することで、安全に同一生成元ポリシーを越えてウェブAPIを利用することができる。また、図1に示すウェブシステム100においては、変更できるオブジェクトや使用できるオブジェクトの個数や属性の文字列長に適切な制限をかけることで、バッファオーバーフローbufferoverflowやヒープスプレイheapspray攻撃など、ウェブブラウザ自体の脆弱性を狙った攻撃を防ぐことができる。<2.変形例>なお、上述実施の形態においては、各オブジェクトに対して設定されるセキュリティ制約が固定であるように説明した。しかし、このセキュリティ制約が、他の条件に応じて動的に変化する例も考えられる。例えば、URLUniformResourceLocatorに従って外部のセキュリティ制約を与える例が考えられる。すなわち、1外部ベンダーが各メジャーサイトを安全に使うために、サイト毎にセキュリティ制約を配布することが考えられる。2そのサイトがセキュリティ制約を持っていない場合、ウェブブラウザがURLに紐付いた制約を適用することが考えられる。図13のフローチャートは、その場合におけるスクリプトエンジンの処理の流れの一例を概略的に示している。スクリプトエンジンは、ステップST11において、処理を開始する。そして、スクリプトエンジンは、ステップST12において、スクリプトの実行が指示されたか否かを判断する。スクリプトの実行が指示されたとき、スクリプトエンジンは、ステップST13の処理に移る。このステップST3において、スクリプトエンジンは、実行指示されたスクリプトの取得先のサイトがセキュリティ制約を持っているか否かを判断する。持っているとき、スクリプトエンジンは、ステップST14において、取得先のサイトが持っているセキュリティ制約を使用することに決定し、その後に、ステップST15の処理に移る。一方、スクリプトエンジンは、ステップST13で取得先のサイトがセキュリティ制約を持っていないとき、ステップST16において、取得先のサイトのURLに紐付いたセキュリティ制約を使用することに決定し、その後に、ステップST15の処理に移る。ステップST15において、スクリプトエンジンは、セキュリティ制約を満たしているか否かを判断する。セキュリティ制約を満たしているとき、スクリプトエンジンは、ステップST17において、スクリプトを実行する。スクリプトエンジンは、このステップST17の処理の後、ステップST18において、処理を終了する。一方、ステップST15でセキュリティ制約を満たしていないとき、スクリプトエンジンは、ステップST19において、スクリプトを実行する代わりに、特殊な動作、例えば、エラー箇所やその原因を示すエラーダイアログを出す等する。スクリプトエンジンは、このステップST19の処理の後、ステップST18におおいて、処理を終了する。また、本技術は、以下のような構成を取ることもできる。1複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理部と、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理部の動作を制御する制御部とを備える情報処理装置。2上記処理部は、ウェブブラウザであり、上記処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトである前記1に記載の情報処理装置。3上記セキュリティ制約は、上記オブジェクト内へのスクリプトの挿入権限である前記2に記載の情報処理装置。4上記セキュリティ制約は、上記オブジェクト内のスクリプトの実行可能権限である前記2または3に記載の情報処理装置。5上記セキュリティ制約は、リクエストに関する制限である前記2から4のいずれかに記載の情報処理装置。6上記セキュリティ制約は、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である前記2から5のいずれかに記載の情報処理装置。7上記セキュリティ制約は、アプリケーションプログラミングインタフェースへのアクセス権限である前記2から6のいずれかに記載の情報処理装置。8上記セキュリティ制約は、異なる生成元からのオブジェクトの参照あるいは変更のリクエストのポリシー変更である前記2から7のいずれかに記載の情報処理装置。9上記セキュリティ制約は、子オブジェクトも含めたヒープ使用量の上限である前記2から8のいずれかに記載の情報処理装置。10上記セキュリティ制約は、子オブジェクトも含めたオブジェクト数の上限である前記2から9のいずれかに記載の情報処理装置。11上記セキュリティ制約は、上記オブジェクトに設定できる文字列長の上限である前記2から10のいずれかに記載の情報処理装置。12上記セキュリティ制約は、上記オブジェクトに属性として与えられる前記2から11のいずれかに記載の情報処理装置。13上記セキュリティ制約は、クラスで指定される前記12に記載の情報処理装置。14上記セキュリティ制約は、セキュリティオブジェクトにより定義される前記2から13のいずれかに記載の情報処理装置。15上記セキュリティ制約の指定のないオブジェクトのセキュリティ制約として、親からのセキュリティ制約を引き継ぐ前記2から14のいずれかに記載の情報処理装置。16所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、該所定のオブジェクトのセキュリティ制約を引き継ぐ前記2から15のいずれかに記載の情報処理装置。17HTTPヘッダにより上記セキュリティ制約を指定する請求項2に記載の情報処理装置。18上記セキュリティ制約は、所定の条件に応じて動的に変化する前記2から17のいずれかに記載の情報処理装置。19複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理ステップと、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理ステップ得の動作を制御する制御ステップとを備える情報処理方法。20コンピュータを、複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理手段と、上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理手段の動作を制御する制御手段として機能させるプログラム。"