Ghosted site page and application page can containe inline code, it is basically traditional aspx page. But all customized(unghosted) site pages are parsed and processed in a special mode known as safe mode. The primary motivation for safe mode involves the fact that standard users can modify the contents of site pages. In other words, a user(such as a site owner) processing no administrator privileges within the farm can make any modifications to a page within a site. Consider a scenario in a large farm in which a site administrator attempts to mount an attack on the Web server by writing C# code within a customized site page inside an in-line script block. Safe mode prevents this type of attack by disallowing in-line script in any customized source. So if your site pages is an instance of page template which has inline code, the site page will break if you modify the site page in the site unless you do something to prevent this happening. For this reason, you should advoid adding in-line script to page templates. If you want o allow in-line scripts to run in unghosted site pages, you can accomplishe this by adding the following PageParserPath element within the SharePoint section of the web.config file.

        <pre data-sub="prettyprint:_">
        <SharePoint>
        <SafeMode ... >
        <PageParserPaths>
        <PageParserPath
        VirtualPath="/sites/Sales/SitePages/*"
        IncludeSubFolders="true"
        CompilationMode="Always"
        AllowServerSideScript="true" />
        </PageParserPaths>
        </SafeMode>
        </SharePoint>

        </pre>


        <p>
        If you examine the PageParserPath element, you see that the VirtualPath attribute has a Web application relative path followed by an asterisk, which includes every site page in that particular folder. Also note that the CompilationMode attribute has a value of Always and the AllowServerSideScript attribute has a value of true. This instructs the safe mode parser to compile all site pages into assembly DLLs and allow in-line script.
        </p><p>
        Note that a page must be compiled into an assembly DLL to support in-line script, which means that it is not valid to assign a value of Never to the CompilationMode attribute while assigning a value of true to the AllowServerSideScript attribute. Also note that you can assign a value of Auto instead of a value of Always to the CompilationMode attribute. This has the effect of compiling only pages that contain in-line script. When the CompilationMode attribute has a value of Auto, pages without in-line script are still run in no-compile mode.
        </p><p>
        It is possible to enable in-line script for all site pages within a Web application by configuring the VirtualPath attribute with a value of /* and then setting the CompilationMode attribute to a value of Always or Auto. However, two significant factors should motivate you not to do this.
        </p><p>
        The first factor is security. By enabling in-line script for all site pages within a Web application, you open the door to attacks on the Web server because any user who has the ability to customize a page can freely write managed code that executes on the Web server.
        </p><p>
        The second factor pertains to scalability. Earlier in this chapter, I discussed how no-compile pages are more scalable than compiled pages in a large Web application. WSS experiences scaling problems if your Web application attempts to compile and load thousands of assembly DLLs for all of your customized pages. At the very least, you should prefer a CompilationMode setting of Auto instead of Always so that only pages that actually contain script are compiled into assembly DLLs, whereas those pages that do not contain script continue to be parsed and processed in no-compile mode.
        </p>

        <h4>Safe Cotnrols</h4>
        <p>
        Safe mode processing goes a step beyond protecting against in-line script by also considering what controls a user might place on a customized page. For example, imagine a scenario in which a site administrator tries to mount an attack by adding a server-side control to a site page and parameterizing it in a certain way. Safe mode allows the farm administrator to determine which controls can be used in pages that are processed in safe mode.
        </p><p>
        Customized pages can only contain server-side controls that are explicitly registered as safe controls. Registering a control as a safe control is accomplished by adding a SafeControl entry into the web.config file for the hosting Web application.
        </p>


        <pre data-sub="prettyprint:_">
        <SafeControls>
        <SafeControl
        Assembly="Microsoft.SharePoint, …"
        Namespace="Microsoft.SharePoint.WebControls"
        TypeName="*"
        AllowRemoteDesigner="True" />
        </SafeControls>


        </pre>


        <p>
        Note that a PageParserPath element, in addition to allowing in-line script, can also override the default safe mode behavior and allow for server-side controls that are explicitly registered as safe. For example, you can allow the users of a particular site to add any server-side controls to customized pages by using the following entry within the web.config file.
        </p>


        <pre data-sub="prettyprint:_">
        <SharePoint>
        <SafeMode ... >
        <PageParserPaths>
        <PageParserPath
        VirtualPath="/sites/Sales/*"
        AllowUnsafeControls="true" />
        </PageParserPaths>
        </SafeMode>
        </SharePoint>

        </pre>


        <p>
        Note that using this option affects only which server-side controls can be added to a page when customizing a page with a tool, such as the SharePoint Designer. This configuration option does not extend to control instances when users are adding Web Parts to Web Part zones on a page through the browser. Assembly DLLs containing Web Parts must always be explicitly registered by using SafeControl elements for users to be able to place them inside Web Part zones.
        </p>
        <p>
        Although you have just learned several ways to disable safe mode or lessen its effects, you should remember to proceed here with extreme caution. It’s usually best to leave safe mode with its default behavior. WSS was engineered with safe mode processing to protect the farm from attacks and allow WSS to scale out the way it was designed in large farm environments.
        </p>