.
| Area | Description |
| Authentication and Authorization | How to choose an authentication strategy. |
| | How to choose an authorization strategy. |
| | How to flow identity across layers and tiers. |
| | How to store user identities when not using Active Directory. |
| Caching and State | How to choose an appropriate caching technology, such as using the .NET Framework cache support or custom caching. |
| | How to determine what data to cache. |
| | How to determine where to cache the data. |
| | How to determine the expiration policy. |
| | How to synchronize caches across a farm. |
| | How to choose between reactive and proactive cache loading. |
| | How to identify state data versus cache data. |
| | How to determine scope requirements for state data, which also determines where state data is persisted. |
| Communication | How to choose appropriate protocols for communication across layers and tiers. |
| | How to design loose coupling across layers. |
| | How to design an interface for communication across AppDomain, process, and physical boundaries. |
| | How to pass data across AppDomain, process, and physical boundaries. |
| | How to perform asynchronous communication. |
| | How to pass sensitive data. |
| Composition | How to choose a composition pattern for the user interface (UI). |
| | How to avoid dependencies between modules in the UI. |
| | How to handle communication between modules in the UI. |
| Concurrency and Transactions | How to handle concurrency between threads. |
| | How to choose between optimistic and pessimistic concurrency. |
| | How to handle distributed transactions. |
| | How to handle long running transactions. |
| | How to determine appropriate transaction isolation levels. |
| | How to determine when compensating transactions are required. |
| Configuration Management | How to determine what information needs to be configurable. |
| | How to determine where and how to store configuration information. |
| | How to protect sensitive configuration information. |
| | How to handle configuration information in a farm/cluster. |
| Coupling and Cohesion | How to choose an appropriate layering strategy for separation of concerns. |
| | How to design highly cohesive components and group them within layers. |
| | How to determine when loose coupling is appropriate between components within a layer. |
| Data Access | How to manage database connections. |
| | How to handle exceptions. |
| | How to improve performance. |
| | How to handle binary large objects (blobs). |
| | How to page records. |
| | How to perform transactions. |
| Exception Management | How to handle exceptions. |
| | How to log exceptions. |
| | How to provide notification when required. |
| _ Logging and Instrumentation_ | How to determine which information to log. |
| | How to make the logging configurable. |
| | How to determine what level of instrumentation is required. |
| User Experience | How to improve task efficiency and effectiveness. |
| | How to improve responsiveness. |
| | How to improve user empowerment. |
| | How to improve look and feel. |
| Validation | How to determine where and how to perform validation. |
| | How to validate for length, range, format, and type. |
| | How to constrain and reject input. |
| | How to sanitize output. |
| Workflow | How to choose the appropriate workflow technology. |
| | How to handle concurrency issues within a workflow. |
| | How to handle task failure within a workflow. |
| | How to orchestrate processes within a workflow. |
| | How to handle the un-deterministic nature of human workflow. |
| Area | Description |
| Authentication and Authorization | Lack of authentication across trust boundaries. |
| | Lack of authorization across trust boundaries. |
| | Granular or improper authorization. |
| | Failure to protect credentials. |
| | Failing to lock down system resources against application identities. |
| Caching and State | Caching data that is volatile. |
| | Caching sensitive data. |
| | Incorrect choice of caching store. |
| | Failure to manage cache lifetime appropriately. |
| | Lack of a cache synchronization mechanism for scaling out. |
| | Using an incorrect state store. |
| | Not considering serialization requirements. |
| | Not persisting state when required. |
| Communication | Incorrect choice of transport protocol. |
| | Chatty communication across physical and process boundaries. |
| | Failure to protect sensitive data. |
| | Large data volumes over limited bandwidth networks. |
| Composition | Lack of consistency in user interface design. |
| | Tight coupling between modules. |
| | Designing overloaded modules that limit reusability. |
| Concurrency and Transactions | Not protecting concurrent access to static data. |
| | Deadlocks caused by improper locking. |
| | Not choosing the correct data concurrency model. |
| | Long running transactions that hold locks on data. |
| | Using exclusive locks when not required. |
| | Using Inappropriate transaction isolation levels. |
| Configuration Management | Not securing sensitive configuration information. |
| | Unrestricted access to configuration information. |
| | Over-privileged process accounts and service accounts |
| Coupling and Cohesion | Incorrect grouping of functionality. |
| | No clear separation of concerns. |
| | Tight coupling across layers. |
| Data Access | Per user authentication and authorization when not required. |
| | Chatty calls to the database |
| | Business logic in the data access layer |
| | Business logic in the database |
| Exception Management | Leaving system / application in unstable state |
| | Revealing sensitive information to end users. |
| | Using exceptions for business logic |
| | Not logging enough details about the exception. |
| | Not considering notification requirements. |
| Logging and instrumentation | Lack of logging and instrumentation |
| | Too fine grained logging and instrumentation |
| | Not making logging and instrumentation configurable option at runtime. |
| | Not suppressing logging failures. |
| | Failure to log business critical functionality. |
| User Experience | Not considering accessibility. |
| | Creating overloaded interfaces with un-related functionality. |
| | Inefficient or ineffective task support. |
| | Poor responsiveness. |
| | Failure to support personalization. |
| Validation | Lack of validation across trust boundaries. |
| | Failure to consider all input data sources for validation. |
| | Not validating for all appropriate aspects of parameters, such as “Range”, “Type” and “Format”. |
| | Not reusing validation logic. |
| | Non-validated input used to generate SQL queries. |
| | Reliance on client-side validation. |
| | Use of input file names, URLs, or user names for security decisions. |
| Workflow | Not considering management requirements. |
| | Tight coupling |
| | Inflexible workflow processes |
| | Race and deadlock issues |
| | Not considering exception states and how to handle them. |
| Area | Description |
| Authentication and Authorization | Consider single-sign on requirements. |
| | Separate public and restricted areas. |
| | Use account lockout policies for end-user accounts. |
| | Support password expiration periods. |
| | Be able to disable accounts. |
| | Do not store passwords in user stores. |
| | Require strong passwords. |
| | Do not send passwords over the wire in plaintext. |
| | Protect authentication cookies. |
| | Use multiple gatekeepers. |
| | Restrict user access to system-level resources. |
| | Consider authorization granularity. |
| Caching and State | Avoid caching per-user data. |
| | Avoid caching volatile data which is required by the user to be accurate and updated in real time. |
| | Cache data that does not change very frequently or is completely static. |
| | Do not cache shared expensive resources. |
| | Cache transformed data, keeping in mind the data use. |
| | Choose an appropriate store for state data. |
| | Minimize session data. |
| | Free session resources as soon as possible. |
| | Avoid accessing session variables from business logic. |
| | Avoid caching sensitive data. |
| Communication | Choose the appropriate remote communication mechanism. |
| | Design chunky interfaces when crossing AppDomain, process, or physical boundaries. |
| | Consider how to pass data between layers. |
| | Minimize the amount of data sent across the wire. |
| | Batch work to reduce calls over the network. |
| | Reduce transitions across boundaries. |
| | Consider asynchronous communication. |
| | Consider a "fire and forget" invocation model where appropriate, such as web service events. |
| | Push out asynchronous boundaries close to the user, service interfaces, and service agents, to isolate your service from external dependencies. |
| Composition | Avoid using dynamic layouts that are difficult to load and maintain. |
| | Be careful with dependencies between components. Use abstraction patterns when possible to avoid issues with maintainability. |
| | Consider creating templates with placeholders. For example use the Template View pattern to compose dynamic web pages to ensure reuse and consistency. |
| | Consider composing views from reusable modular parts. For example use the Composite View pattern to build a view from modular, atomic component parts. |
| | Use well-known design patterns to implement a composite interface containing separate modules or user controls where appropriate. |
| | Modules should not directly reference one another or the application that loaded them. |
| | Modules should use services to communicate with the application or with other modules. |
| | Modules should not be responsible for managing their dependencies. |
| | Modules should support being added and removed from the system in a pluggable fashion. |
| Concurrency and Transactions | Reduce contention by minimizing lock times. |
| | Balance between coarse- and fine-grained locks. |
| | Choose an appropriate transaction isolation level. |
| | Avoid long-running atomic transactions. |
| | Consider using compensating locks for long running or disconnected transactions. |
| Configuration Management | Protect your sensitive configuration data. |
| | Restrict access to the configuration store. |
| | Maintain separate administration privileges. |
| | Use least privileged process and service accounts. |
| Coupling and Cohesion | Partition application functionality into logical layers. |
| | Design for loose coupling across layers. |
| | Design components for high cohesion. |
| | Use early binding where possible. |
| | Use tight coupling within layers unless dynamic behavior requires loose coupling. |
| Data Access | If your application uses a single database, use the database-specific data provider. |
| | If you need to support multiple databases, you generally need to have an abstraction layer, which helps you transparently connect to the currently configured store. |
| | Consider resource throttling to maximize concurrent access. |
| | Consider the identities you flow to the database. |
| | Separate read-only and transactional requests. |
| | Avoid unnecessary data returns. |
| Exception Management | Avoid revealing sensitive data to users. |
| | Do not use exceptions to control application flow. |
| | Use validation code to avoid unnecessary exceptions. |
| | Do not catch exceptions that you cannot handle. |
| | Be aware that re-throwing is expensive. |
| | Preserve as much diagnostic information as possible in your exception handlers. |
| | Always catch exceptions at the boundary layers. |
| Logging and instrumentation | Instrument your code up front. |
| | Instrument for business and system critical events. |
| | Make your logging configurable. |
| | Do not log sensitive information. |
| | Backup and analyze log files on a regular basis. |
| User Experience | Measure effectiveness against scenarios. |
| | Improve user responsiveness where possible. |
| | Model from effective user design. |
| | Avoid creating overloaded interfaces with un-related functionality. |
| | Design for accessibility. |
| | Consider localization requirements up front. |
| Validation | Assume all input is malicious. |
| | Validate for length, range, format, and type. |
| | Constrain and reject input. |
| | Sanitize output. |
| | Don’t rely on client-side validation. |
| Workflow | Determine management requirements. If a business user needs to manage the workflow, you’ll need a solution that provides an interface that the business user can understand. |
| | Determine how exceptions will be handled. |
| | With human workflow, you need to consider the un-deterministic nature of humans. In other words, you can’t determine when a task will be completed, or if it will be completed correctly. |
| | Use service interfaces to interact with external workflow providers. |
| | If supported, use designers and metadata to define the workflow instead of code to define the workflow. |