How to use static values (parameters) from web.config file

If you have static values that you use across your .NET application, one place to store these values is the web.config file.

Let’s say you use your application’s name in several pages in your application. Instead of hard coding this value in each page, it’s easier and more efficient to store it as a parameter in the web.config file.

Example record in web.config:

<add key="APPLICATION_NAME" value="My application"/>

In order to read this value in your code-behind file, use this line:


Best practices for session state and cookies in ASP.NET application

Session state best practices:

  • Reconfigure the default session id name in order to obfuscate the true meaning of the cookie value. In the case of ASP.NET, the default name is ASP.NET_SessionId. This immediately gives away that the application is ASP.NET and that that cookie contains the session id value.
  • Ensure the length of the session id is long enough to prevent brute force attacks. Recommended length is 128 bits.
  • Ensure the session id is created in a truly random way. This ensures that attackers can’t guess the session id due to some predictability analysis.
  • Ensure that the session id does not contain any additional sensitive data. Instead, the value should be nothing more than a random string of characters with no meaning other than the session id as a whole.
  • HTTPS should be employed for all session based applications handling sensitive data.
  • Session cookies should be created with the Secure and HttpOnly attributes set.
  • Prevent concurrent sessions where possible.
  • Destroy sessions upon timeout, logoff, browser close or log-in from a separate location.

Cookie best practices:

  • Do not store any critical information in cookies. For example, do not store a user’s password in a cookie, even temporarily. As a rule, do not keep anything in a cookie that, if spoofed, can compromise your application. Instead, keep a reference in the cookie to a location on the server where the information is.
  • Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible.
  • Consider encrypting information in cookies.
  • Consider setting the Secure and HttpOnly properties on the cookie to true.

Code examples

In order to implement best practices for cookies, add the code lines below into your application.

Web.config file:

<sessionState regenerateExpiredSessionId="false" cookieless="UseCookies" cookieName="id" />

Code-behind file:

Response.Cookies.Add(new HttpCookie("id", ""));
Response.Cookies["id"].HttpOnly = true;
Response.Cookies["id"].Secure = Convert.ToBoolean(ConfigurationManager.AppSettings["SecureCookie"]);


How to remove server data from response headers of your ASP.NET application?

The less you give to hackers, the safer your web application is. Hiding the product, technology, and version information of your server is one big step towards narrowing the attack surface of your application.

By default, IIS server will reveal this data to everyone who has access to your application:

Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET

This data can be viewed by a proxy such as Fiddler.

Server details
Server details

You can remove these headers by add a few lines into web.config and Global.asax files. You don’t need to do any configuration changes in IIS if you are using IIS 7 or an upper version.

Remove “Server” header

Add this method into Global.asax:

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)

Add this line into Application_Start in Global.asax:

PreSendRequestHeaders += Application_PreSendRequestHeaders;

Remove “X-AspNet-Version” header

Add this line into web.config:

     <httpRuntime enableVersionHeader="false" />

Remove “X-Powered-By” header

Add this line into web.config:

               <remove name="X-Powered-By" />