ASP.NET Coding Standards Details
Home > Application Development > Application Standards > ASP.NET Coding Standards > ASP.NET Coding Standards Details
ASP.NET Coding Standards Details
1. AJAX programming, controls, and frameworks are not to be used
Understandability, Learnability, Complexity
Guideline
AJAX (Asynchronous JavaScript and XML) is a web development technique for
creating interactive applications that behave much like ordinary desktop
applications. However, for AJAX to work correctly, JavaScript must be
supported and enabled in the web browser. AJAX development techniques
are more complex than traditional web development as an asynchronous
paradigm is used for sending and receiving fragments of data in the
background. The received fragments are then used to dynamically update portions of the web
page without requiring a complete refresh of the page.
Some of the reasons to avoid AJAX include:
Reliance on JavaScript support
Increased coding and debugging complexity
Not fully supporting web browser history integration (i.e. Back
button will not work as expected)
Difficult to bookmark a URL representing a particular state in the
application
Introduces difficulties with Web Analytics solutions as user actions
are harder to track
Harder to have pages indexed by search engines unless Site Maps are
provided
Requirement
AJAX programming techniques and associated frameworks are not to be
used in development of web applications.
Checking Process
Examine HTML files for inline or referenced JavaScript files
for use of AJAX techniques:
Search for XMLHttpRequest or MSXML2.XMLHTTP for use of
AJAX-related browser objects
Search for AJAX string to identify use of
AJAX methods
provided by Prototype
JavaScript framework (http://www.zjjv.com/)
Search for scriptaculous string to identify use of
script.aculo.us (script.aculo.us) library
Examine ASP.NET page files (.aspx) for inline server script or
code-behind files (.aspx.vb) for use of AJAX frameworks:
Search for XMLHttpRequest or MSXML2.XMLHTTP for use of
AJAX-related browser objects
Search for AJAX string to identify use of AJAX methods (http://www.zjjv.com//api/ajax) provided by Prototype JavaScript framework (http://www.zjjv.com/)
Search for scriptaculous string to identify use of
script.aculo.us (script.aculo.us) library
Search for System.Web.UI to identify use of
ASP.NET AJAX Framework (asp.net/ajax/documentation/live/) classes
such as "UpdatePanel", "Timer", "ScriptControl", etc
If in doubt, disable JavaScript in browser and then verify
application still functions correctly (see standard
Web site is fully-functional when JavaScript is disabled in the browser).
Example of including JavaScript framework libraries supporting AJAX
<script src="javascripts/prototype.js" type="text/javascript"></script>
<script src="javascripts/scriptaculous.js" type="text/javascript"></script>
References
AJAX (programming) (en.wikipedia.org/wiki/AJAX) (Wikipedia)
Prototype JavaScript
Framework (http://www.zjjv.com/) (see AJAX (http://www.zjjv.com//api/ajax) section)
Script.aculo.us library (script.aculo.us) (see controls (wiki.script.aculo.us/scriptaculous/tags/controls) section)
Back to Contents
2. Web site is partitioned into restricted areas
(protected using SSL) and public areas
Security, Performance
Guideline
Web sites containing both restricted and public areas should be
partitioned so that all restricted pages are placed under one or more
subdirectories under the root web virtual directory. Each subdirectory
which is part of the restricted area of the web site must be configured to
require authenticated access.
URL Authorization (msdn2.microsoft.com/en-us/library/wce3kxhd(vs.80).aspx) can be used to restrict access to secure
subdirectories. To restrict access to a subdirectory, place
<authorization> elements in a Web.config file. Either multiple <authorization> elements within separate
<location> elements can be used in the application-level
Web.config file or separate Web.config
files can be placed in each restricted subdirectory with their own
<authorization> element.
Separating public areas from restricted areas avoids incurring SSL
performance overheads across the entire site.
Restricted areas must always use SSL to mitigate the risk of session
hijacking by always sending authentication keys to HTTPS connections - not
HTTP connections.
Any redirects from a HTTP (public, anonymous) page to a HTTPS (restricted,
secure) page (and vice-versa) must use absolute URLs.
Note: Server.Transfer
must not be used to transfer from an anonymous page to a secure page since
authentication checks are bypassed by the .NET Framework.
Requirement
Web sites that consist of both public (anonymous) and restricted
(secure) areas should be partitioned to separate the restricted
content into one or more subdirectories.
Restricted subdirectories are protected by requiring
authenticated access (configured in the <authorization>
section of the Web.config file)
All links referencing a restricted page must use HTTPS URLs to
protect authentication keys.
Redirects from an anonymous page (HTTP) to a secure page (HTTPS)
must use absolute URLs to protect against transferring
authentication keys in plain text.
Server.Transfer is not used to
redirect from an anonymous page to a secure page to prevent
bypassing of authentication checks.
Unauthenticated access to restricted pages (e.g. expired session)
should redirect to the default login page.
Example
Sample of application-level Web.config with URL Authorization
"The <authentication> section enables configuration of the security authentication
mode used by ASP.NET to identify an incoming user.
""The virtual directory root folder contains general pages.
Unauthenticated users can view them and they do not need
to be secured with SSL. ">
<!-- The restricted folder (named "Secure") is for authenticated and SSL access only.
Deny access to unauthenticated users and force a redirect to the login page that is
specified on the <forms> element.
=">
""
Sample of placing a separate Web.config in the restricted folder named "Secure"
"""
Exemption
If the web site has only anonymously accessible content then there is
no need to partition the site.
Checking Process
Check that restricted areas of the site are partitioned into separate
subdirectories:
All restricted pages and controls are located in these
subdirectories.
Check restricted subdirectories are configured to require
authenticated access in a Web.config file.
Check that the restricted subdirectories are configured in IIS to
require SSL:
Click the Edit button in the "Secure
communications" area
Require secure channel (SSL) should be checked
to require HTTPS to be used (note: a certificate must be installed
for the web site in order for SSL to be usable)
Check that all URLs that reference restricted pages use HTTPS
protocol (https://).
Check that any redirects (Response.Redirect)
in ASP.NET code-behind files use absolute URLs:
Redirects to restricted pages use HTTPS (https://)
Redirects to anonymous pages use HTTPS (http://)
Check ASP.NET code-behind files do not use
Server.Transfer is to redirect from an anonymous pages (http://)
to a secure page (https://)
Check that unauthenticated access to restricted pages redirects to the default login page.
References
ASP.NET Authorization (msdn2.microsoft.com/en-us/library/wce3kxhd(vs.80).aspx) (MSDN Library)
Chapter 10 - Building Secure ASP.NET Pages and Controls (msdn2.microsoft.com/en-us/library/aa302426.aspx) (MSDN Library)
How To: Set Up SSL on a Web Server (msdn2.microsoft.com/en-us/library/aa302411.aspx) (MSDN Library)
Back to Contents
3. Code-behind files are used rather than inline
server-side script blocks
Modularity, Complexity, Understandability, Learnability
Guideline
ASPX (page) and ASCX (user control) files should not contain any inline
server-side scripting. ASPX and ASCX files should only contain the
visual elements of the page such as HTML and server controls, static text,
CSS, etc. The programming logic for the page should be contained in a
separate file called a Code-behind file. Programming logic consists
of event handlers and other .NET code.
Note: The code-behind model is the default model used
for new pages when working in Visual Studio .NET.
It is considered bad practice to mix HTML/XHTML and programming code in
the same physical file. Inline programming code appears in
blocks with the
runat="server" attribute value. Inline programming mixed with HTML/XHTML is harder to
understand, maintain, and reuse.
Code-behind files provide a clean separation of UI programming logic from
presentation elements. Another advantage is that designers can work on the
ASPX files in parallel to developers working on the code-behind file. Designers do not see the inline programming logic in their files.
Note: Commonly used code in page code-behind files can
be moved to a base class so that other page code-behind classes derive from
this base class and inherit common functionality. This allows code to
be reused and avoids duplication of code in every page.
Requirement
Every ASP.NET Page should use the Code-Behind Model by separating UI
presentation element into the .aspx
file and programming logic into a .aspx.vb file (in the
case of Visual Basic).
Every ASP.NET Web User Control should use the Code-Behind Model by
separating UI presentation element into the .ascx file and programming logic into a
.ascx.vb file (in the case of Visual Basic).
No inline <script
runat="server">
... blocks appear in the .aspx/.ascx files.
Checking Process
Check every .aspx (page) file:
No blocks with runat="server" should be found.
A corresponding Code-behind file should existing with the same
name but .aspx.vb extension (in the case of Visual
Basic).
Check every .ascx (user control) file:
No blocks with runat="server" should be found.
A corresponding Code-behind file should existing with the same
name but .ascx.vb extension (in the case of Visual
Basic).
References
ASP.NET Web Page Code Model (msdn2.microsoft.com/en-us/library/015103yb(VS.80).aspx) (MSDN Library)
Embedded Code Blocks in ASP.NET Web Pages (msdn2.microsoft.com/en-us/library/ms178135(VS.80).aspx) (MSDN Library)
Back to Contents
4. Code-behind files are not used as a container for
Business Logic and/or Data Access Logic
Complexity, Modularity, Generality, Scalability,
Understandability, Learnability
Guideline
Do not place data-access or business-logic code in code-behind files. Code-behind
files should only contain UI programming logic such as event handlers for
ASP.NET server controls and page events. Place data-access code and
business-logic into classes located in a separate class library (called an
assembly in .NET).
Note: If business logic is performed solely in
stored-procedures in the database then data-access code should still be
located in a separate assembly which accesses these stored procedures.
Code-behind files form what is known as the "presentation" layer in a
three-layer programming model. Business logic code and data-access
code should be placed in separate layers. Separating these
"concerns" into different layers is a tenet of good software design.
Separating the business-logic and data-access logic into separate class
libraries allows deployment of this logic into a separate physical tiers
(such as an Application Server) and supports scaling out the web application
if required.
Requirement
Code-behind files should only contain presentation-related
programming logic such as event handlers which work with the UI elements
(ASP.NET Server Controls, HTML Controls).
Code-behind files can make use of data-access and/or business logic
classes referenced in separate class libraries.
Code-behind files must not directly contain data-access code (such as
ADO.NET classes or the Data Access Application Block) or business logic
rules
Input validation for form fields, query strings, etc, is
allowed.
Exemption
Typed or untyped DataSets (and associated classes like DataTables,
DataRows, DataColumns, DataViews, etc) can be used from the ADO.NET
namespace System.Data for data binding to GridView, DataList,
and Repeater controls. Other ADO.NET classes should not be used in
the presentation logic.
Checking Process
Check code-behind files for use of ADO.NET classes:
Check for references to namespaces starting with System.Data
Namespaces other than System.Data should
not be referenced (e.g. System.Data.SqlClient)
Classes other those forming part disconnected ADO.NET
architecture (DataSet, DataTable,
DataColumn, DataRow,
DataView, DataRelation,
Constraint, etc) should not be used.
IDataReader interface should not be used
(since it relies on the connected model of data access via a
stream)
Check for references to the Data Access Application Block
Search for Microsoft.ApplicationBlocks.Data
References
Embedded Code Blocks in ASP.NET Web Pages (msdn2.microsoft.com/en-us/library/ms178135(VS.80).aspx) (MSDN Library)
Back to Contents
5. Master Pages are used as a means to create a
consistent layout for web applications
Generality, Complexity, Understandability
Guideline
Master Pages are the preferred method of creating standard layout
templates in ASP.NET 2.0 when creating a consistent layout for a site.
In a typical web application, some areas of the page are common to all
pages such as the header, footer, menus, etc. A Master Page allows
the factoring out of common features to be shared by all pages and each specific
page using the Master Page can then add its own unique content to the
designated content placeholders.
Master Pages are only supported in ASP.NET 2.0 or higher. Previously, Server-Side Include (classic ASP), or referenced User Controls
(ASP.NET 1.x) were used to create common layout templates.
Some disadvantages with Server-Side Includes:
No IDE support for editing files that have SSI directives
Easy to have unbalanced tags or insert content into wrong location
Difficult for pages to alter elements in the includes templates
(e.g. setting the page title)
Some disadvantages with referencing and using User Controls on each page:
Requires each page to use the @Register directive to reference each
User Control
User Controls do not specify the layout themselves, they are merely
reusable components to appear on pages
Changing the position of a User Control on one page requires a change to
multiple pages across the site
There is no concept of a shared layout; each page must specify the
location of each referenced control
No Visual Studio designer integration for viewing templated page
using User Controls (VS.NET 2003)
Requires "clever" custom programming techniques to achieve shared
templates by injecting controls into well-know locations in the page
control hierarchy
Reasons to use Master Pages for creating consistent layouts:
Visual Studio 2005 integrated designer support
Standard way to create templated sites in ASP.NET 2.0
Master Pages act as templates for Content Pages which fill in the
content placeholders
Master Pages use Visual Inheritance rather than Class
Inheritance
Master Pages can be nested within other Master Pages
Master Pages can provide default content for their content
placeholders
Requirement
Use Master Pages for creating a shared common layout for the web
application.
Do not use User Controls outside of a Master Page to create a common
layout for a group of pages.
User Controls can be used within Master Pages.
Exemption
Master Pages were introduced in ASP.NET 2.0. Versions prior to
this do not support Master Pages and a custom method of templating must
be used. Typically, this involves adding User Controls to every
page in a consistent fashion in order to achieve a standard layout.
Checking Process
Check for presence of .master files which indicate Master Pages.
Check to see that the other ASP.NET pages (.aspx) reference these
master pages (via the MasterPageFile attribute of
@Page directiveat the top of the page):
"~/SiteTemplate.master" %>
If Master Pages are not used, search the ASP.NET pages (.aspx files)
for @Register directive at the top of the file.
Note down the controls which are being used on each page and
determine if any of these is repeated on all or a subset of pages such
that the controls always appear in the same location on all the pages
(look for headers, footers, menus, navigation bars, and similar
controls).
References
Master Your Site Design with Visual Inheritance and Page
Templates (http://http://www.zjjv.com///en-au/magazine/cc163967.aspx) (MSDN Magazine)
Master Pages in ASP.NET 2.0 (msdn2.microsoft.com/en-us/library/ms379585(VS.80).aspx) (MSDN Library)
Master Pages (http://www.zjjv.com//learn/moving-to-asp.net-2.0/module-04.aspx) (The Official Microsoft ASP.NET 2.0 site)
Back to Contents
6. Commonly used page elements are separated into Web User
Controls and/or Web Custom Controls
Modularity, Complexity
Guideline
Commonly used page elements should be placed in separate controls to
avoid duplication of code, facilitate code/component reuse, improve
maintainability, and caching effectiveness.
Web User Controls should be used to group several ASP.NET server controls
(and HTML) together to form a single composite control which can be reused
throughout the application (e.g. on Master Pages).
Web User Controls are recommended as they are easier to implement and
have integrated designer support.
Web Custom Controls can also be used if controls are to be shared across
multiple web applications, however, they must be implemented
programmatically without integrated designer support.
Web User Controls can take advantage of fragment caching if content does
not vary often which can improve the web application performance.
When factoring out common functionality in controls, try to separate
static content from dynamic content to allow page output and fragment
caching to be use more effectively.
Requirement
Commonly used page elements should be placed in separate web user or
custom controls.
Checking Process
Examine the web application pages in Visual Studio:
For content which appears to be similar across more than one
page, check that web user controls or custom controls have been used to
avoid duplication of code and mark-up.
Web user controls are contained in files ending in .ascx
and control the @Control directive at the top
of the file.
Other pages (including Master Pages) can use the controls by
referencing them via the @Register directive
near the top of the file.
References
Building Maintainable Web Interfaces with ASP.NET (msdn2.microsoft.com/en-us/library/ms978615.aspx) (MSDN
Library)
Recommendations for Web User Controls vs. Web Custom Controls (msdn2.microsoft.com/en-us/library/aa651710(VS.71).aspx)
(MSDN Library)
Back to Contents
7. Web site is fully-functional when JavaScript is
disabled in the browser
Recoverability
Guideline
Web sites can use JavaScript to improve the user experience as long as
they are fully-functional when JavaScript is disabled in the web browser. Some users may choose to disable JavaScript for security reasons or their
browser may not support it.
Do not rely on client-side scripting for enforcing business rules or
validating input. It can be easily bypassed when JavaScript is
disabled.
Requirement
Web sites must be fully-functional when JavaScript is disabled.
Checking Process
Look for parts of the application which appear to function
dynamically without posting back to the server (thus avoiding a full
page refresh).
Disable JavaScript in the web browser.
Check that the application functions correctly.
References
Back to Contents
8. Server-side validation is performed on all user inputs from sources such as HTML controls, Query String, and Cookies
Security
Guideline
Server side validation of user input is required to help prevent invalid
or malicious data getting into the system. Malicious data can include
Script injection or SQL injection attacks.
User inputs can come from sources such as:
All input form fields should be validated using the ASP.NET validation
server controls. These built-in server controls save the developer a
lot of time and effort in validating their HTML form inputs.
Client-side validation of input form fields can save round-trips to the
server which improves performance, however, custom validation scripts should
be avoided when an ASP.NET validation server control can do the job. The ASP.NET validation server controls automatically detect if the browser
supports JavaScript and if it is enabled. They then generate the
client-side validation scripts behind the scenes when the page is loaded
without any work from the developer (except for the CustomValidator
control).
The other reason to avoid writing client-side validation scripts is that
they can be easily bypassed by disabling JavaScript in the browser (see
standard Web site is fully-functional when JavaScript is
disabled in the browser).
The validation code should check that the length, type, and range of data
is valid. For enumerations, check against a known legal set of values.
For data type checking, use TryParse methods and check the
Boolean result, rather than Parse which throws an exception
upon invalid data.
Any problems found with the input data should be communicated back to
the user in a clear and concise manner. When echoing user inputs back to the
user always HTML encode the echoed values to foil any maliciously injected
scripts.
For multi-tier applications where the business logic and/or data access
layer code reside on a middle-tier (e.g. an Application Server) it is
important to re-validate any inputs since you cannot rely on inputs having
come from a known source (such as the Web Server). The
Validation
Application Block (msdn2.microsoft.com/en-us/library/bb410105.aspx) can be used for coding validation rules into your
business logic and/or data access layer code.
Requirement
All user inputs are validated server-side.
Example
A HTML form MyForm contains a text field MyField that
expects a mandatory value
between 10 and 30.
When the data is submitted to the server it must be checked for the
following:
Checking Process
Check the server-side code for evidence of input data validation.
References
ASP.NET validation server controls:
Validating ASP.NET Server Controls (msdn2.microsoft.com/en-us/library/Aa479013.aspx) (MSDN Library)
Validation Form Input Controls (quickstarts.asp.net/QuickStartv20/aspnet/doc/validation/default.aspx) (ASP.NET QuickStart Tutorials)
Validating inputs in other tiers:
Validation Application Block (msdn2.microsoft.com/en-us/library/bb410105.aspx) (MSDN Library)
Back to Contents
9. Input form field values are retained when form is
redisplayed to the user after input validation fails
Guideline
When data validation is performed and an incorrect scenario has been
detected an appropriate message is returned to the user. In this instance
the data that had previously been entered by the user must be preserved.
Requirement
Data entered by the user is to be preserved when submission of the
form input data fails due to input validation errors.
Checking Process
Enter the application and perform the following:
Fill out a form of the application with at least on field
containing invalid data.
Submit the data to the application.
After the validation message has been received check that the
original form is displayed and that it contains the data previously
entered.
References
Back to Contents
10. Data paging is used for unbounded or long lists of data
Performance
Guideline
The nature of some applications means there is potential for large amounts
of data to be returned to the browser. Very long lists of data
returned to the client browser can cause
problems with performance and scalability due to the increased network traffic
and server utilisation while sending back the response. There are also usability
issues as it is hard to navigate a page which displays too many records.
To mitigate these problems data paging should be used to limit the
number of records that can be retrieved and displayed at any given point.
Data paging is the practice of displaying a limited number of records
per page with links to the next, previous, or a specific page of records that are returned by a
query.
The number of records returned per page is dependent on many
factors (msdn2.microsoft.com/en-us/library/ms978510.aspx#daag_datapaging) of the system
and the nature of the data being displayed. However, as a guide each
page should not exceed 50 records.
Requirement
Data paging must be used if a query can return more than 50 records.
Checking Process
Access the application and perform the following steps:
Check that the search results are limited to a reasonable number
of records and there is a method of navigating to any records not
currently displayed.
References
Data Paging (msdn2.microsoft.com/en-us/library/ms978510.aspx#daag_datapaging) section of
.NET Data Access Architecture Guide (msdn2.microsoft.com/en-us/library/ms978510.aspx) (MSDN Library)
Efficiently Paging Through Large Amounts of Data (http://www.zjjv.com//learn/data-access/tutorial-25-vb.aspx) (The
Official Microsoft ASP.NET 2.0 site)
Back to Contents
11. Data that is frequently used but changes
infrequently is cached using ASP.NET Caching
Performance
Guideline
Data that is frequently accessed by the application and is common for all
users should be cached using ASP.NET Caching.
ASP.NET caching can significantly improve performance and scalability of
a web application under specific scenarios.
Scenarios where ASP.NET Caching is a good fit:
Data that changes infrequently or only needs to be refreshed after a
specific interval (e.g. every 5 mins)
Scenarios where ASP.NET Caching is not a good fit:
Data that changes per request and stale versions of the data are not
acceptable
The ASP.NET Cache object provides programmatic access to
a shared data cache and should be used over the Application
object for caching data as it supports features such as cached item
dependencies, priorities, and expiration policies.
When an ASP.NET application runs low on memory resources a process known
as scavenging executes which removes cached items based on their priorities.
The Application object does not support any of these
advanced features. However, it can still be used as a read-only memory
cache for small amounts of global data that are populated only at
application start up which are guaranteed to be in memory rather than
possibly requiring database access.
ASP.NET Pages or User Controls which are dynamically built from static or
infrequently changing data can use Page Output or Fragment Caching as an
alternative to programmatic use of the ASP.NET Cache
object.
Requirement
Static or infrequently changing data that is frequently accessed by
the application should be cached using ASP.NET Caching, if the following
criteria are met:
Data to be cached is common/shared amongst all/many users of the
application - not user specific
Exemption
Sensitive data should not be cached.
Pages or User Controls which display sensitive data should not be
cacheable.
care should be taken when caching Large datasets as memory resources
may be compromised
Checking Process
Identify areas of the application where frequently accessed
non-user-specific data is being used:
Check that the data is not being retrieved and/or constructed
for each user request.
Check to see that a caching mechanism is being used.
The ASP.NET Cache can be identified by
searching for the System.Web.Caching
namespace and Cache class.
Page output and fragment caching can be identified by
searching ASP.NET pages (.aspx) and user controls (.ascx) for
the
@OutputCache (msdn2.microsoft.com/en-us/library/hdxfb6cy(VS.80).aspx) directive.
Use of the intrinsic Application object for storing read/write
data can be identified using the
Practices Checker (http://www.zjjv.com//PracticesChecker) tool on the
web site project and selecting the "Use Application
State to Share Static, Read-Only Data" rule.
References
Using the ASP.NET Cache (msdn2.microsoft.com/en-us/library/ms978500.aspx#cachingarchch2_usingaspnetcache) section of
Caching Architecture Guide for .NET Framework Applications (msdn2.microsoft.com/en-us/library/ms978500.aspx)
(MSDN Library)
ASP.NET Caching (msdn2.microsoft.com/en-us/library/xsbfdd8c(vs.80).aspx) (MSDN Library)
Caching ASP.NET Pages (msdn2.microsoft.com/en-us/library/06bh14hk(VS.80).aspx) (MSDN Library)
@ OutputCache (msdn2.microsoft.com/en-us/library/hdxfb6cy(VS.80).aspx) (MSDN Library)
Back to Contents
12. Pooled resources (e.g. Database
connections) are not cached
Scalability
Guideline
Pooled resources such as database connections should not be cached as
this reduces the availability of the pooled resource for other users of the
application leading to scalability issues.
Requirement
Pooled resources are not to be cached.
Checking Process
Check the code to ensure that pooled resources are released as soon
as their job is completed.
The Practices
Checker (http://www.zjjv.com//PracticesChecker) tool can be used to detect caching of pooled resources by
selecting the "Do Not Cache or Block on Pooled Resources" rule.
References
Back to Contents
13. Sensitive data is not cached
using ASP.NET caching or in the Application state
Security
Guideline
Sensitive or confidential data should not be cached using ASP.NET caching
or Application state as data stored in this manner is available to all users
of the application and presents a security and privacy risk.
If sensitive data needs to be cached it is recommended that it is stored in
the Session State for each user.
Requirement
Sensitive data (such as passwords) must not be cached in using ASP.NET
caching or Application state.
Checking Process
Identify senseitive data used in the web application.
Check the code to ensure that sensitive datais not being
stored in the ASP.NET Cache object or Application state
object.
Check ASP.NET Pages (.aspx) and User Controls (.ascx) to ensure they
do not cache sensitive data (with the @OutputCache
directive):
<%@ OutputCache
Duration="100"
VaryByParam="None"
%> - caches the page for 100
seconds.
<%@ OutputCache
Location="None"
%> - indicates
page output/fragment caching is disabled.
References
Caching Architecture Guide for .NET Framework Applications (msdn2.microsoft.com/en-us/library/ms978500.aspx)
(MSDN Library)
Back to Contents
14. Sensitive information such as passwords and
connection strings are not stored in any client-side state
Security
Guideline
Sensitive information must not be stored client side as it can be easily
viewed or tampered with which can compromise the security of the application
and related systems.
Requirement
Do not store sensitive information (even if encrypted) using the
client-side state such as Query Strings, Hidden form fields, Cookies,
and View State.
Checking Process
Identify sensitive data used by the web application.
Check the code to ensure sensitive data such as passwords or connection strings
are not assigned to any client-side state.
References
Back to Contents
15. Web site is fully-functional when cookies are
disabled in the browser
Security, Recoverability
Guideline
Cookies can represent a security risk for some users and so cookies may
be disabled in the client browser. This cannot be controlled by the
application so the application must be designed in such a way that it does
not depend on cookies to function correctly.
Requirement
The web site must operate normally if cookies are disabled in the
browser.
Checking Process
Disable cookies in the browser then access the application.
Ensure that all functionality performs as expected.
References
Back to Contents
16. Session state is disabled for web applications and only enabled for
individual pages that require it
Performance
Guideline
Session state should only be enabled for the pages that require it. This minimises the server resources used (e.g. memory) and improves performance
as session state does not be retrieved, de-serialised, updated, serialised,
and finally stored per user request.
Performance impact becomes more noticeable when out-of-process session
state such as a SQL Server database is used for persisting session state.
Requirement
Session state is disabled in the web.config file and only enabled for individual pages that require it.
Session state is set to ReadOnly for pages that do not modify session
state but need read access to it.
Example
In web.config, disable session state by default
"For pages that both read and update session state
"True" %>For pages that only read session state
"ReadOnly" %>Checking Process
Check that session state has not been enabled for pages that do not
require it.
The Practices
Checker (http://www.zjjv.com//PracticesChecker) tool can be used to detect pages that have session state enabled but that could potentially have session state disabled by selecting the Disable Session State If You Do Not Use It rule.
References
(msdn2.microsoft.com/en-us/library/ms998549.aspx#scalenetchapt06_topic18) section of Chapter 6 - Improving ASP.NET Performance (msdn2.microsoft.com/en-us/library/ms998549.aspx) (MSDN Library)
Back to Contents
17. View State is disabled for web applications and
only enabled for individual controls that require it
Performance
Guideline
View state should only be enabled for the controls that require it. This
minimises the server resources used and improves performance of the application.
Large amounts of view state increases the page size so sending content to
the client takes longer.
View state can be disabled on a page if the
following conditions are true (msdn2.microsoft.com/en-us/library/ms998549.aspx#scalenetchapt06_topic19):
The page does not post back to itself
The page code behind does not handle server control events
Server controls on the page have their data repopulated with every
page refresh
Requirement
View state is disabled in the web.config file andonly enabled for individual
controls that require it.
Example
A control that needs to retain its state during a post back of data
should have view state enabled.
In web.config, disable view state by default
"For controls that require view state enabled
"true" runat="server" />Checking Process
Check that controls that are not required to maintain state do not
have view state enabled.
The Practices
Checker tool can be used to detect pages that have view state enabled
but that could potentially have
view state disabled by selecting the "Disable view state if you
do not need it" rule.
References
(sdn2.microsoft.com/en-us/library/ms998549.aspx#scalenetchapt06_topic19) section of Chapter 6 - Improving ASP.NET Performance (msdn2.microsoft.com/en-us/library/ms998549.aspx) (MSDN Library)
Back to Contents
18. View State is not enabled for data bound controls such as drop-down lists, check box lists,
grid views, repeaters, etc
Performance
Guideline
View state should not be enabled for data bound controls as they should
rebind their data each time the page is refreshed. The amount of data
that may need to be maintained in the view state can become prohibitive for
these controls. This can lead to resource and performance issues as
a large View State needs to be sent back and forth between the client and server.
ASP.NET Data bound controls include:
GridView (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.gridview(VS.80).aspx) (which replaces the
DataGrid (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.datagrid(VS.80).aspx))
FormView (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.formview(VS.80).aspx)
DetailsView (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.detailsview(VS.80).aspx)
Repeater (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.repeater(VS.80).aspx)
DataList (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.datalist(VS.80).aspx)
Requirement
Data bound controls such as drop-down lists, grid views etc must not
have view state enabled.
Checking Process
Search for data bound server controls in the ASPX files (.aspx
extension).
For example, to check for the GridView (msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.gridview(VS.80).aspx) control, search for asp:gridview:
"CustomersGridView"
datasourceid="CustomersSqlDataSource"
autogeneratecolumns="true"
autogeneratedeletebutton="true"
autogenerateeditbutton="true"
datakeynames="CustomerID"
Check that data bound controls do not have view state enabled (see
standard View State is disabled for web applications
and only enabled for individual controls that require it for
how to check if view state is enabled).
References
Back to Contents
19. The DataGrid server control is not used
Maintainability
Guideline
The DataGrid control has been superseded in the .NET Framework 2.0 by the GridView control. This
new control should be used in place of the DataGrid as it has
several improvements (msdn2.microsoft.com/en-us/library/05yye6k9(VS.80).aspx) over the DataGrid.
A secondary problem is that some parts of the DataGrid will not work
correctly if View State is disabled. These include Editing, Sorting,
and Paging since the server-side events for these features will not fire.
However, it is possible to get around this issue with some
additional work (msdn2.microsoft.com/en-us/library/aa478966.aspx#aspnet-commondatagridmistakes_topic8).
Requirement
The DataGrid control is not to be used.
Checking Process
Check that any grids within the application make use of the GridView
and not the DataGrid control:
Search for asp:datagrid to see
if DataGrids are used.
References
Comparing the GridView and DataGrid Web Server Controls (msdn2.microsoft.com/en-us/library/05yye6k9(VS.80).aspx)
(MSDN Library)
Enduring an Over-sized ViewState (msdn2.microsoft.com/en-us/library/aa478966.aspx#aspnet-commondatagridmistakes_topic8) section of
Common Datagrid Mistakes (msdn2.microsoft.com/en-us/library/aa478966.aspx) (MSDN Library)
Back to Contents
20. Objects are not stored in the session state
Performance
Guideline
Objects should not be stored in the session state as
serialisation/de-serialisation of objects is slower than serialisation of
primitive types such as String, DateTime, Integer, Double, Guid, etc.
If the application uses objects to represent data kept in the session
state, store the individual attributes as key/name pairs rather than the
whole object as a single key/value pair. When retrieving the session
state, rebuild the object from the constituent attribute key/name pairs.
Flattening an object's attributes into separate session key/value pairs
provides an additional performance advantage: on-demand de-serialisation. Only those attributes which are accessed will be de-serialized. Similarly, only those key/value pairs which are modified will be serialised
back into the session state (and any out-of-process session store such as
SQL Server or ASP.NET State Server).
Requirement
Do not store objects using session state.
Only store primitive types in the session state.
Checking Process
Check the code to ensure that objects are not being stored in session
state:
Search for code that stores data in the Session
object
Session("accountDetails") = accountInfo
References
Fast, Scalable, and Secure Session State Management for Your Web
Applications (msdn.microsoft.com/msdnmag/issues/05/09/SessionState/default.aspx) (MSDN Magazine)
Back to Contents
21. Application state is only used for sharing
application-wide read-only data for all clients
Performance, Security
Guideline
Application state should only be used for storing application-wide
read-only data that can be shared by all clients. The recommended
approach is to load the required static data in the
Application_Start event in an ASP.NET Application file (Global.asax (msdn2.microsoft.com/en-us/library/1xaas8a2(vs.71).aspx)).
Data should not be written to the Application state since changes are not
synchronised across servers in a web farm.
User-specific data should not be stored in the Application state, use
Session state for that purpose.
Sensitive data should not be stored in the Application state as it is
globally accessible by all code in the application and access is not
constrained to a specific user.
Avoid storing large amounts of data in the Application state as the
memory cannot be reclaimed when system resources are low. Use the
ASP.NET Cache instead for caching large amounts of read-only data as it
supports scavenging cached items when memory is low.
Requirement
Application state must only contain read-only application-wide data.
Application state is only populated at application start up.
Application state is not used for storing:
Checking Process
Check that all data stored using application state is applicable to
the application as a whole:
Search for code that stores data in the Application
object
Application("dbConnectionString") = connectionString
References
ASP.NET Application State Overview (msdn2.microsoft.com/en-us/library/ms178594(VS.80).aspx) (MSDN Library)
Back to Contents
22. HTTP error codes are handled using custom error
reporting pages
Security
Guideline
HTTP errors that occur when a client request is processed should be
handled using custom error reporting pages.
Custom error messages retain the look and feel of the site (rather than
the default error pages presented by the browser) and provide an opportunity
to display additional information to the user (such as tech support
information).
Custom error pages are set up in the Web.config file in
the <customErrors (msdn2.microsoft.com/en-us/library/h0hfz6fc(vs.80).aspx)> section.
A default redirect page should be provided for displaying a generic error
message (used when a specific error page is not provided). This is done via
the defaultRedirect attribute.
Specific error pages should be provided for common HTTP Error codes such
as:
Note: Never set the mode attribute to
Off as detailed errors are then shown directly to remote
users.
Requirement
Custom error reporting pages are enabled in the web.config file.
A default redirect page is provided for generic error reporting.
Specific error pages are provided for common HTTP error codes.
The mode attribute is not set to Off
in the customErrors element (On
or RemoteOnly are acceptable).
Example
Example of enabling customer errors (in the web.config file) with a default redirect page and specific errors pages.
"""
Checking Process
Check the web.config file to see that custom error
reporting is turned on and a default redirect page is provided.
Specific error pages are provided for common HTTP error codes (see
above).
The
Best Practice Analyzer for ASP.NET (msdn2.microsoft.com/en-us/vstudio/aa718345.aspx) tool can be used to check a
web.config fileto verify the
customErrors section is set correctly for a production environment.
References
How to: Display Safe Error Messages (msdn2.microsoft.com/en-us/library/994a1482(VS.80).aspx) (MSDN Library)
customErrors Element (ASP.NET Settings Schema) (msdn2.microsoft.com/en-us/library/h0hfz6fc(vs.80).aspx) (MSDN
Library)
Back to Contents
23. Unhandled exceptions are caught using an
application-level global error handler
Security
Guideline
Unhandled exceptions within an application should be caught and managed
in a consistent and safe manner. This can be best achieved by using a global
error handler that can trap all unhandled exceptions, log the details, then
present a safe error page to the user (without exposing any sensitive data).
Note: If you redirect to another page in a Global Error
Handler, it takes precedence over the defaultRedirect page
in the customErrors element of a web.config
file. If you do not redirect to another page in the Global Error
Handler, the defaultRedirect page is used (so ensure one is specified).
Requirement
Exceptions are processed using an application-level global error
handler.
Example
Sample Global Error Handler (Visual Basic)
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
' Get the error message of the unhandled exception.
Dim errorMessage As String = Server.GetLastError.Message
' TODO: Do something with the error, e.g.
' - Send an email
' - Log the error details, stack trace, etc.
' Transfer to custom error page.
Server.Transfer("ReportError.aspx")
End Sub
Checking Process
Check the project for the presence of a Global.asax
file which contains a Global Error Handler (Application_Error
event handler).
This can also be checked using the
Practices Checker (http://www.zjjv.com//PracticesChecker)
tool by using the "Implement a Global.asax error handler" rule.
Check that the Global Error Handler does at least the following
tasks:
Logs the server exception
Redirects to a safe error page (either explicitly or via the
defaultRedirect attribute of the
customErrors element in the web.config file, see standard
HTTP error codes are handled using custom error
reporting pages)
References
Creating a Global Error Handler section of
How to: Display Safe Error Messages (msdn2.microsoft.com/en-us/library/994a1482(VS.80).aspx) (MSDN Library)
Back to Contents
24. Configurable application settings are stored in the web application's Web.config file
Maintainability
Guideline
Application settings which are subject to change when the application is
deployed into different environments should be placed in an
ASP.NET Configuration File (msdn2.microsoft.com/en-us/library/ms178684(VS.80).aspx) (named web.config).
The web.config file hasmany pre-defined sections for commonly
configured settings such as database connection strings. Additional
application settings can be added to the web.config file.
The .NET Framework provides the WebConfigurationManager
(located in the System.Web.Configuration namespace) class
for working with web application settings.
Requirement
Configurable application settings should be stored in the web.config
file.
Do not use the Windows Registry or custom files (e.g. INI files) for
storing web application settings.
Checking Process
Check the web application for deployed files
that are used for storing application settings.
Only the web.config file should be used for application settings
Search the source code for use of the Windows Registry:
Search for use of the Registry (msdn2.microsoft.com/en-us/library/microsoft.win32.registry(VS.80).aspx) class which is part of the
Microsoft.Win32 (msdn2.microsoft.com/en-us/library/microsoft.win32(vs.80).aspx) namespace
References
WebConfigurationManager Class (msdn2.microsoft.com/en-us/library/system.web.configuration.webconfigurationmanager(vs.80).aspx) (MSDN Library)
ASP.NET Configuration Files (msdn2.microsoft.com/en-us/library/ms178684(VS.80).aspx) (MSDN Library)
Back to Contents
25. Request validation is enabled to prevent scripting
attacks
Security
Guideline
Request validation should be enabled to protect against Script Injection
attacks. Request validation prevents processing of a client request when
it detects embedded HTML elements (such as <script>)
or reserved characters.
If HTML input is required from users then care should be taken to
constrain the allowed HTML tags to a small set of "safe" tags. This
requires manual server-side checking (e.g. using Regular Expressions (msdn2.microsoft.com/en-us/library/ms998267.aspx)).
Requirement
Request validation is always enabled.
Exemption
If HTML input is required from users, request validation can be
turned off at the page level. However, adequate server-side
validation and sanitisation of the input data must be done.
See Sanitizing Free-Text Fields and Allowing Restricted HTML Input in
the article
How
To: Protect From Injection Attacks in ASP.NET (msdn2.microsoft.com/en-us/library/bb355989.aspx) for further
details.
Checking Process
Check the web.config file to ensure request
validation is enabled for the entire web application:
"
Check for individual pages that have disabled request validation:
"false" %>
Ensure necessary validation has been implemented on the
server-side to protected against Script Injection attacks.
References
Back to Contents
26. Page output buffering is enabled
Performance
Guideline
Page output buffering reduces server round trips thus avoiding chatty
communication between client and server. There is a significant
performance cost for disabling buffering of pages.
Requirement
Page output buffering is enabled for all pages.
Checking Process
Check output buffering has not been disabled at the application level
by checking the web.config file:
"true" .>
Check output buffering has not be disabled at the page (.aspx) level
by check all pages:
"false" %>
Check output buffering has not been disabled in source code
programmatically by checking all source for:
Response.BufferOutput = True
Or you can use the Practices
Checker (http://www.zjjv.com//PracticesChecker) tool to ensure page output buffering is enabled by selecting
the "Enable Buffering" rule.
References
References go here...
Back to Contents
27. ASP.NET tracing and debugging are disabled
Performance, Security
Guideline
ASP.NET tracing and debugging should be disabled for web applications in
a production environment.
Debugging reduces the performance of an application.
Tracing is a potential security risk as sensitive application tracing
data and server variables can be viewed from an ordinary web browser.
Requirement
ASP.NET Tracing and Debugging should be disabled in a production
environment.
Checking Process
Check the web.config file to ensure ASP.NET Tracing
and Debugging are disabled:
""
Check individual ASP.NET pages (.aspx) to ensure tracing and debugging have
not been turned on, thus overriding the setting in the web.config file.
"True" Trace="True" ... %>
The
Best Practice Analyzer for ASP.NET (msdn2.microsoft.com/en-us/vstudio/aa718345.aspx) tool can check a
web.config file to verify ASP.NET tracing and debugging are set
correctly for a production environment.
References
ASP.NET Tracing (msdn2.microsoft.com/en-us/library/y13fw6we(vs.80).aspx) (MSDN Library)
Debugging ASP.NET Web Pages (msdn2.microsoft.com/en-us/library/8t6y55xx(VS.80).aspx) (MSDN Library)
Back to Contents
28. Database connection string should be encrypted
Security
Guideline
Encrypting the database connection string in a web.config to prevent the exposure of the database login and password.
Requirement
Database connection string in Web.Config file MUST be encrypted
Checking Process
Check the web.config file to ensure <configProtectedData> is used.
Liaise with WebFarm Administrator to arrange for web.config encrypted in Production.
References
Encrypting Sections of the Web.config File (msdn2.microsoft.com/en-us/library/y13fw6we(vs.80).aspx) (MSDN Library)
Back to Contents
