In addition to section 1.1 of the Store Certification Requirements, which is general enough to allow rejection of any app that just attempt to wrap a website, section 3.9 come into the picture when you have a legitimate app that wants to use web content in some way:
3.9 All app logic must originate from, and reside in, your app package
Your app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code or data that changes how the application interacts with the Windows Runtime, or behaves with regard to Store policy. It is not permissible, for example, to download a remote script and subsequently execute that script in the local context of your app package.
The wording of this policy certainly allows for hosting web content within an <iframe> element (HTML/JS) apps or a WebView control (XAML apps). A number of reader apps (as for blogs) do this routinely, where the app is processing an RSS feed to provide a nice view of the overall content, then displays specific posts within an iframe/webview. That hosted content can run script within its iframe/webview sandbox.
In such cases, the app typically provides for different view states, handles touch input, provides app bars and appropriate navigation controls, and might implement other OS integration points that clearly add value. That is, while the app is clearly hosting web content, it’s not relying entirely on that hosted content for the user experience.
Now an app might have pages that are entirely created with hosted content, where that web site is set up to provide a user experience that is indishtinguishable from a native app. The tricky part here is supporting functions like snapped view, which would have to be done with responsive CSS design and so forth. The app would also need to pass messages (via postMessage in HTML or InvokeScript in XAML) to implement things like app bar commands.
So would such a thing violate section 3.9 above? It’s something of a gray area. The key factors are (a) whether the hosted content attempts to modify the in-package contents through injection of HTML/JS, and (b) whether you’re attempting to pass script or other data that would cause the main app, which has access to the WinRT API, to behave in a way that either breaks Store policy or changes the behavior of the app from what it says it does.
What’s really at stake here is user safety and confidence. First, dynamic injection of script and other content within the app can pose security risks that the user may not be aware of. Second, such a dynamic nature can deviate well away from what the app says it does in the Store, hence eroding user confidence because it makes it possible for an app to say one thing in the Store and do completely different things at runtime.
This is really to say that all content that interacts with the WinRT API must be included in the app package, so bringing down any kind of script or code and executing that within the app (e.g. in the local context of an HTML/JS app) is not allowed. Bringing down HTML/CSS/JS (or XAML for that matter) and rendering that in a sandboxed viewport of some kind (which includes implementing your own renderer) is allowable.