Skip to content

Finding bugs from web.config file in ASP.NET

If you are a tester who is testing a product that is developed on ASP.NET technology then this post would educate you in finding bugs in web.config file. Web.config is a configuration file wherein, you include details such as,

  1. Data Source
  2. SMTP Server
  3. Authentication
  4. Custom Error / Re-direction
  5. Session timeout
  6. Cookie exceptions


And many more details.


Example #1

Let’s say you are testing web application for session timeout and you are not aware when it would happen. At such times you might directly go to the /inetpub/wwwroot/ and go to the folder where application is deployed and open the web.config with any text editor (Notepad++ – Recommended) and search for string like “timeout” and now, you see that you get the details. You might also see that there is no timeout XML tag which means you have found a bug which is there is no timeout of session.


Example #2

We are experiencing delay in sending or receiving e-mail address. We purchased a cool SMTP server from some cool vendor. In such situation you could go to web.config and see if the SMTP server has the same incoming and outgoing servers which were purchased from that cool vendor. Now, that should be your first test. In case if it’s the same then you need to contact that cool vendor who turned to be not a cool vendor.


Example #3

Handling error pages – Let’s say when there is no page that server is looking for, an error page is displayed. Now, there are different status codes and these could be handled in web.config file. You can go to web.config and see if the developer is using custom error pages for all these. You can search for “customErrors” string to find the details if any.


For the list of HTTP status code you can refer here.


To be continued in the next blog post – Thanks!


I have been as a software tester for over 5 years. I am a hands-on tester and I've been winning bug battles & testing competitions across the world. I am a testing enthusiast, who conducts free workshops on security testing across India (Covered locations: Bengaluru, Pune, Hyderabad & Chennai. Invite him to come to your location), and monthly meets for testers in Bengaluru. I am also an avid testing blogger.

My interests include traveling, driving my SUV, health & fitness and many others. I mentor budding entrepreneurs, testers, teams in any profession.

Latest posts by SanthoshTuppad (see all)



  1. Example#1
    What if you see the timeout is 20 seconds set in web.config but the site is actually sending request from client to server in every seconds to keep you alive? The timeout doesn’t always guarantee the actual timeout in application.

    Common error pages are not always handled from web.config. They can be handled from IIS even. Actually there are numerous way to handle it. So, if you don’t see any error page information in web.config doesn’t necessarily mean that common errors are not handled in that app.

    Thursday, August 11, 2011 at 12:01 am | Permalink
  2. Exactly! A tester need to investigate from other different areas from where this configuration could be done.

    Web.config is one of the area where you could search for such configurations. Custom error pages could be done from web.config or as you said from IIS or from Control Panel of the hosting provider.

    Talking about timeout it depends on what timeout we are talking about, is it inactivity timeout or timeout irrespective of being active or inactive. The timeout could be even handled from specific pages instead of web.config; it depends on what kind of need is to be targeted.

    Monirul, Thanks for bringing this point. Newbies would just have concluded over web.config if they are not aware that web.config is one of the way different configurations could be set.

    — Santhosh Tuppad

    Thursday, August 11, 2011 at 12:15 am | Permalink
  3. Ravisuriya wrote:

    With my very little learning working with JSP pages and WAR files, see the PROPERTIES file having similar details.

    This PROPERTIES file will be under /webapps/app-name/WEB-INF/classes/lib. There might be changes in naming or directory structure as application server varies.

    Tweaking the contents of properties file and restarting the server, has helped seeing vulnerabilities which is not so apparent to normal observations.

    Like said above ‘Data Source’ or ‘Database’ connection value and driver can have interesting behavior on application.

    Taking the backup of test environment properties file, editing the values to point as programmer machine environment can show problems that comes from hard coded values.

    Also witnessed application looks to be normal on using the previous properties file though changes have come in latest release or build for deployment configuration.

    Most times or unusually this properties file will be copy pasted from different project or application to existing application. Now not removing the configuration details of other project or application, can bring in probably severe risks when application is shipped.

    At times, the properties file be start point of investigation for unexpected behavior from deployed application. A properties file of an application can have connection URL and access credentials to another applications deployed on other server or on same server different port or the same port. This brings in conflict and can bypass the access restrictions, if not handled in invoking application.

    Have more such mistakes committed while I was testing. Thought this could help testers, hence shared.

    Thursday, August 11, 2011 at 12:18 am | Permalink
  4. Ram wrote:

    #1: time out does not have to be in web.config file. IIS has other features timeouts. It also depends on the approach taken for the session management for the respective applications.

    good compile/observation on the web.config; i agree, the configuration testing of web app should look for testing the web.config for any custom configurations.

    occassionally application’s business rules can be stored in web.config as well, provided the configuraiton required for website to function / behave in certain way.

    Thursday, August 11, 2011 at 12:31 am | Permalink

Post a Comment

Your email is never published nor shared. Required fields are marked *