Hossein Zahed

Web Developer, Entrepreneur, Software Educator

Visual Studio 15 (2017) will let developers install only the components they need

  1. Universal Windows Platform development
  2. Web development (incl. ASP.NET, TypeScript, Azure tooling)
  3. Windows desktop app development with C++
  4. Cross-platform mobile development with .NET (incl. Xamarin)
  5. .NET desktop application development
  6. Linux and IoT development with C++
  7. Cross-platform mobile development with Cordova
  8. Mobile app development with C++ (incl. Android, iOS)
  9. Office / SharePoint add-in development
  10. Python web development (incl. Django and Flask support)
  11. Data science and analytical applications (incl. R, F#, Python)
  12. Node.js development
  13. Cross-platform game development (incl. Unity)
  14. Native Windows game development (incl. DirectX)
  15. Data storage and processing (incl. SQL, Hadoop, Azure ML)
  16. Azure cloud services development and management
  17. Visual Studio extension development

What technical details should a programmer of a web application consider before making the site public?

The idea here is that most of us should already know most of what is on this list. But there just might be one or two items you haven't really looked into before, don't fully understand, or maybe never even heard of.

Interface and User Experience

  • Be aware that browsers implement standards inconsistently and make sure your site works reasonably well across all major browsers. At a minimum test against a recent Gecko engine (Firefox), a WebKit engine (Safari and some mobile browsers), Chrome, your supported IE browsers (take advantage of the Application Compatibility VPC Images), and Opera. Also consider how browsers render your site in different operating systems.
  • Consider how people might use the site other than from the major browsers: cell phones, screen readers and search engines, for example. — Some accessibility info: WAI and Section508, Mobile development: MobiForge.
  • Staging: How to deploy updates without affecting your users. Have one or more test or staging environments available to implement changes to architecture, code or sweeping content and ensure that they can be deployed in a controlled way without breaking anything. Have an automated way of then deploying approved changes to the live site. This is most effectively implemented in conjunction with the use of a version control system (CVS, Subversion, etc.) and an automated build mechanism (Ant, NAnt, etc.).
  • Don't display unfriendly errors directly to the user.
  • Don't put users' email addresses in plain text as they will get spammed to death.
  • Add the attribute rel="nofollow" to user-generated links to avoid spam.
  • Build well-considered limits into your site - This also belongs under Security.
  • Learn how to do progressive enhancement.
  • Redirect after a POST if that POST was successful, to prevent a refresh from submitting again.
  • Don't forget to take accessibility into account. It's always a good idea and in certain circumstances it's alegal requirementWAI-ARIA and WCAG 2 are good resources in this area.
  • Don't make me think



  • Implement caching if necessary, understand and use HTTP caching properly as well as HTML5 Manifest.
  • Optimize images - don't use a 20 KB image for a repeating background.
  • Learn how to gzip/deflate content (deflate is better).
  • Combine/concatenate multiple stylesheets or multiple script files to reduce number of browser connections and improve gzip ability to compress duplications between files.
  • Take a look at the Yahoo Exceptional Performance site, lots of great guidelines, including improving front-end performance and their YSlow tool (requires Firefox, Safari, Chrome or Opera). Also, Google page speed (use with browser extension) is another tool for performance profiling, and it optimizes your images too.
  • Use CSS Image Sprites for small related images like toolbars (see the "minimize HTTP requests" point)
  • Busy web sites should consider splitting components across domains. Specifically...
  • Static content (i.e. images, CSS, JavaScript, and generally content that doesn't need access to cookies) should go in a separate domain that does not use cookies, because all cookies for a domain and its subdomains are sent with every request to the domain and its subdomains. One good option here is to use a Content Delivery Network (CDN), but consider the case where that CDN may fail by including alternative CDNs, or local copies that can be served instead.
  • Minimize the total number of HTTP requests required for a browser to render the page.
  • Utilize Google Closure Compiler for JavaScript and other minification tools.
  • Make sure there’s a favicon.ico file in the root of the site, i.e. /favicon.icoBrowsers will automatically request it, even if the icon isn’t mentioned in the HTML at all. If you don’t have a /favicon.ico, this will result in a lot of 404s, draining your server’s bandwidth.

SEO (Search Engine Optimization)

  • Use "search engine friendly" URLs, i.e. use example.com/pages/45-article-title instead of example.com/index.php?page=45
  • When using # for dynamic content change the # to #! and then on the server $_REQUEST["_escaped_fragment_"] is what googlebot uses instead of #!. In other words, ./#!page=1 becomes ./?_escaped_fragments_=page=1. Also, for users that may be using FF.b4 or Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); Is a great command. So even though the address bar has changed the page does not reload. This allows you to use ? instead of #! to keep dynamic content and also tell the server when you email the link that we are after this page, and the AJAX does not need to make another extra request.
  • Don't use links that say "click here". You're wasting an SEO opportunity and it makes things harder for people with screen readers.
  • Have an XML sitemap, preferably in the default location /sitemap.xml.
  • Use <link rel="canonical" ... /> when you have multiple URLs that point to the same content, this issue can also be addressed from Google Webmaster Tools.
  • Use Google Webmaster Tools and Bing Webmaster Tools.
  • Install Google Analytics right at the start (or an open source analysis tool like Piwik).
  • Know how robots.txt and search engine spiders work.
  • Redirect requests (using 301 Moved Permanently) asking for www.example.com to example.com (or the other way round) to prevent splitting the google ranking between both sites.
  • Know that there can be badly-behaved spiders out there.
  • If you have non-text content look into Google's sitemap extensions for video etc. There is some good information about this in Tim Farley's answer.


  • Understand HTTP and things like GET, POST, sessions, cookies, and what it means to be "stateless".
  • Write your XHTML/HTML and CSS according to the W3C specifications and make sure they validate. The goal here is to avoid browser quirks modes and as a bonus make it much easier to work with non-traditional browsers like screen readers and mobile devices.
  • Understand how JavaScript is processed in the browser.
  • Understand how JavaScript, style sheets, and other resources used by your page are loaded and consider their impact on perceived performance. It is now widely regarded as appropriate to move scripts to the bottom of your pages with exceptions typically being things like analytics apps or HTML5 shims.
  • Understand how the JavaScript sandbox works, especially if you intend to use iframes.
  • Be aware that JavaScript can and will be disabled, and that AJAX is therefore an extension, not a baseline. Even if most normal users leave it on now, remember that NoScript is becoming more popular, mobile devices may not work as expected, and Google won't run most of your JavaScript when indexing the site.
  • Learn the difference between 301 and 302 redirects (this is also an SEO issue).
  • Learn as much as you possibly can about your deployment platform.
  • Consider using a Reset Style Sheet or normalize.css.
  • Consider JavaScript frameworks (such as jQueryMooToolsPrototypeDojo or YUI 3), which will hide a lot of the browser differences when using JavaScript for DOM manipulation.
  • Taking perceived performance and JS frameworks together, consider using a service such as theGoogle Libraries API to load frameworks so that a browser can use a copy of the framework it has already cached rather than downloading a duplicate copy from your site.
  • Don't reinvent the wheel. Before doing ANYTHING search for a component or example on how to do it. There is a 99% chance that someone has done it and released an OSS version of the code.
  • On the flipside of that, don't start with 20 libraries before you've even decided what your needs are. Particularly on the client-side web where it's almost always ultimately more important to keep things lightweight, fast, and flexible.

Bug fixing

  • Understand you'll spend 20% of your time coding and 80% of it maintaining, so code accordingly.
  • Set up a good error reporting solution.
  • Have a system for people to contact you with suggestions and criticisms.
  • Document how the application works for future support staff and people performing maintenance.
  • Make frequent backups! (And make sure those backups are functional) Have a restore strategy, not just a backup strategy.
  • Use a version control system to store your files, such as SubversionMercurial or Git.
  • Don't forget to do your Acceptance Testing. Frameworks like Selenium can help. Especially if you fully automate your testing, perhaps by using a Continuous Integration tool, such as Jenkins.
  • Make sure you have sufficient logging in place using frameworks such as log4jlog4net or log4r. If something goes wrong on your live site, you'll need a way of finding out what.
  • When logging make sure you capture both handled exceptions, and unhandled exceptions. Report/analyse the log output, as it'll show you where the key issues are in your site.

Lots of stuff omitted not necessarily because they're not useful answers, but because they're either too detailed, out of scope, or go a bit too far for someone looking to get an overview of the things they should know. Please feel free to edit this as well, I probably missed some stuff or made some mistakes.

ASP.NET Security Architecture Cheat Sheet For Very Busy Architects

Application Security Meeting

From my experience application security meetings are usually hard to manage since the participants do not share common language. Security guys come from infrastructure background and developers usually ... just hate security. There is a communication gap that results in antagonism prolonging the problem instead of solving it. There is the need for common language that everyone understands. The cheat sheet below helped me many times to establish the common ground for fruitful discussion. It is based on JD Meier's epic works:

Have fun.

The Cheat Sheet

Architecture and Design Issues for Web Applications

ASP.NET Security Architecture

Building Secure Assemblies

The main threats are:

  • Unauthorized access or privilege elevation, or both
  • Code injection
  • Information disclosure
  • Tampering

Secure .Net assemblies

Building Secure ASP.NET Pages and Controls

The main threats are:

  • Code injection
  • Session hijacking
  • Identity spoofing
  • Parameter manipulation
  • Network eavesdropping
  • Information disclosure

Secure ASP.NET pages

Building Secure Serviced Components

The main threats are:

  • Network eavesdropping
  • Unauthorized access
  • Unconstrained delegation
  • Disclosure of configuration data
  • Repudiation

Secure Serviced Components

Building Secure Web Services

The main threats are:

  • Unauthorized access
  • Parameter manipulation
  • Network eavesdropping
  • Disclosure of configuration data
  • Message replay

Secure Web Services

Building Secure Remoted Components

The main threats are:

  • Unauthorized access
  • Network eavesdropping
  • Parameter manipulation
  • Serialization

Secure Remoted Components

Building Secure Data Access

The main threats are:

  • SQL injection
  • Disclosure of configuration data
  • Disclosure of sensitive application data
  • Disclosure of database schema and connection details
  • Unauthorized access
  • Network eavesdropping

Secure Data Access Components


Complimentary questionnaire



Identify threats

Identify vulnerabilities

Common Vulnerabilities


·          How could an attacker spoof identity?

·          How could an attacker gain access to the credential store?

·          How could an attacker mount a dictionary attack? How are your user's credentials stored and what password policies are enforced?

·          How can an attacker modify, intercept, or bypass your user's credential reset mechanism?


·          Are user names and passwords sent in clear text over an unprotected channel? Is any ad hoc cryptography used for sensitive information?

·          Are credentials stored? If they are stored, how are they stored and protected?

·          Do you enforce strong passwords? What other password policies are enforced?

·          How are credentials verified?

·          How is the authenticated user identified after the initial logon?


·          Passing authentication credentials or authentication cookies over unencrypted network links, which can lead to credential capture or session hijacking

·          Using weak password and account policies, which can lead to unauthorized access

·          Mixing personalization with authentication



·          How could an attacker influence authorization checks to gain access to privileged operations?

·          How could an attacker elevate privileges?


·          What access controls are used at the entry points of the application?

·          Does your application use roles? If it uses roles, are they sufficiently granular for access control and auditing purposes?

·          Does your authorization code fail securely and grant access only upon successful confirmation of credentials?

·          Do you restrict access to system resources?

·          Do you restrict database access?

·          How is authorization enforced at the database?


·          Using over-privileged roles and accounts

·          Failing to provide sufficient role granularity

·          Failing to restrict system resources to particular application identities


Input and Data Validation

·          How could an attacker inject SQL commands?

·          How could an attacker perform a cross-site scripting attack?

·          How could an attacker bypass input validation?

·          How could an attacker send invalid input to influence security logic on the server?

·          How could an attacker send malformed input to crash the application?


·          Is all input data validated?

·          Do you validate for length, range, format, and type?

·          Do you rely on client-side validation?

·          Could an attacker inject commands or malicious data into the application?

·          Do you trust data you write out to Web pages, or do you need to HTML-encode it to help prevent cross-site scripting attacks?

·          Do you validate input before using it in SQL statements to help prevent SQL injection?

·          Is data validated at the recipient entry point as it is passed between separate trust boundaries?

·          Can you trust data in the database?

·          Do you accept input file names, URLs, or user names? Have you addressed canonicalization issues?


·          Relying exclusively on client-side validation

·          Using a deny approach instead of allow for filtering input

·          Writing data you did not validate out to Web pages

·          Using input you did not validate to generate SQL queries

·          Using insecure data access coding techniques, which can increase the threat posed by SQL injection

·          Using input file names, URLs, or user names for security decisions


Configuration Management

·          How could an attacker gain access to administration functionality?

·          How could an attacker gain access to your application's configuration data?


·          How do you protect remote administration interfaces?

·          Do you protect configuration stores?

·          Do you encrypt sensitive configuration data?

·          Do you separate administrator privileges?

·          Do you use least privileged process and service accounts?


·          Storing configuration secrets, such as connection strings and service account credentials, in clear text

·          Failing to protect the configuration management aspects of your application, including administration interfaces

·          Using over-privileged process accounts and service accounts


Sensitive Data

·          Where and how does your application store sensitive data?

·          When and where is sensitive data passed across a network?

·          How could an attacker view sensitive data?

·          How could an attacker manipulate sensitive data?


·          Do you store secrets in persistent stores?

·          How do you store sensitive data?

·          Do you store secrets in memory?

·          Do you pass sensitive data over the network?

·          Do you log sensitive data?


·          Storing secrets when you do not need to store them

·          Storing secrets in code

·          Storing secrets in clear text

·          Passing sensitive data in clear text over networks


Session Management

·          Do you use a custom encryption algorithm, and do you trust the algorithm?

·          How could an attacker hijack a session?

·          How could an attacker view or manipulate another user's session state?


·          How are session cookies generated?

·          How are session identifiers exchanged?

·          How is session state protected as it crosses the network?

·          How is session state protected to prevent session hijacking?

·          How is the session state store protected?

·          Do you restrict session lifetime?

·          How does the application authenticate with the session store?

·          Are credentials passed over the network and are they maintained by the application? If they are, how are they protected?


·          Passing session identifiers over unencrypted channels

·          Prolonged session lifetime

·          Insecure session state stores

·          Session identifiers in query strings



·          What would it take for an attacker to crack your encryption?

·          How could an attacker obtain access to encryption keys?

·          Which cryptographic standards are you using? What, if any, are the known attacks on these standards?

·          Are you creating your own cryptography?

·          How does your deployment topology potentially impact your choice of encryption methods?


·          What algorithms and cryptographic techniques are used?

·          Do you use custom encryption algorithms?

·          Why do you use particular algorithms?

·          How long are encryption keys, and how are they protected?

·          How often are keys recycled?

·          How are encryption keys distributed?


·          Using custom cryptography

·          Using the wrong algorithm or a key size that is too small

·          Failing to protect encryption keys

·          Using the same key for a prolonged period of time


Parameter Manipulation

·          How could an attacker manipulate parameters to influence security logic on the server?

·          How could an attacker manipulate sensitive parameter data?


·          Do you validate all input parameters?

·          Do you validate all parameters in form fields, view state, cookie data, and HTTP headers?

·          Do you pass sensitive data in parameters?

·          Does the application detect tampered parameters?


·          Failing to validate all input parameters. This makes your application susceptible to denial of service attacks and code injection attacks, including SQL injection and XSS.

·          Including sensitive data in unencrypted cookies. Cookie data can be changed at the client or it can be captured and changed as it is passed over the network.

·          Including sensitive data in query strings and form fields. Query strings and form fields are easily changed on the client.

·          Trusting HTTP header information. This information is easily changed on the client.


Exception Management

·          How could an attacker crash the application?

·          How could an attacker gain useful exception details?


·          How does the application handle error conditions?

·          Are exceptions ever allowed to propagate back to the client?

·          What type of data is included in exception messages?

·          Do you reveal too much information to the client?

·          Where do you log exception details? Are the log files secure?


·          Failing to validate all input parameters

·          Revealing too much information to the client


Auditing and Logging

·          How could an attacker cover his or her tracks?

·          How can you prove that an attacker (or legitimate user) performed specific actions?


·          Have you identified key activities to audit?

·          Does your application audit activity across all layers and servers?

·          How are log files protected?


·          Failing to audit failed logons

·          Failing to protect audit files

·          Failing to audit across application layers and servers



Related Materials

Transaction log is full. How do I shrink it?

This KB article describes how MS SQL database transaction log can be shrunk in case if one day your system has stopped working showing the error:

'Transaction Log is Full' (Error 9002) 

The error means that restricted maximum size of the transaction log file of your Easy Projects database was reached. 

You must shrink the transaction log by executing one of the following scripts depending on the version of your MS SQL Server.


For MS SQL Server 2005 the script is as follows:

USE <DatabaseName>
DBCC SHRINKFILE (<TransactionLog>, 1)
DBCC SHRINKFILE(<TransactionLog>, 1)


For MS SQL Server 2008 / 2008R2:

ALTER DATABASE <DatabaseName> set recovery simple
DBCC SHRINKFILE (<TransactionLog>,1)
ALTER DATABASE <DatabaseName> set recovery full


<DatabaseName> - the name of your EP database, e.g. "EasyProjects",

<TransactionLog> - logical name of EP database log file, e.g. "EasyProjects_log".


In order to find out what is the logical name of your EP database log file:

1) Open the SQL Server management studio,

2) Right-click on your EP database and choose Properties,

3) Click on the 'Files' tab.