This is a handy list to have.  This is the top 25 most dangerous programming errors relating to the web and keeping websites (and user data) safe. Be sure when you are building and using frameworks that you do test or expect these types of behaviors.

The Top 25 is organized into three high-level categories that contain multiple CWE entries.

Insecure Interaction Between Components

These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.

• CWE-20: Improper Input Validation
• CWE-116: Improper Encoding or Escaping of Output
• CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
• CWE-79: Failure to Preserve Web Page Structure (aka ‘Cross-site Scripting’)
• CWE-78: Failure to Preserve OS Command Structure (aka ‘OS Command Injection’)
• CWE-319: Cleartext Transmission of Sensitive Information
• CWE-352: Cross-Site Request Forgery (CSRF)
• CWE-362: Race Condition
• CWE-209: Error Message Information Leak

Risky Resource Management

The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.

• CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
• CWE-642: External Control of Critical State Data
• CWE-73: External Control of File Name or Path
• CWE-426: Untrusted Search Path
• CWE-94: Failure to Control Generation of Code (aka ‘Code Injection’)
• CWE-494: Download of Code Without Integrity Check
• CWE-404: Improper Resource Shutdown or Release
• CWE-665: Improper Initialization
• CWE-682: Incorrect Calculation

Porous Defenses

The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.

• CWE-285: Improper Access Control (Authorization)
• CWE-327: Use of a Broken or Risky Cryptographic Algorithm
• CWE-259: Hard-Coded Password
• CWE-732: Insecure Permission Assignment for Critical Resource
• CWE-330: Use of Insufficiently Random Values
• CWE-250: Execution with Unnecessary Privileges
• CWE-602: Client-Side Enforcement of Server-Side Security

PDF Editions

1-column for viewing online

2-column for printing

Table of Contents

Dedication

Acknowledgments

Curriculum Vitae

Abstract of the Dissertation

Introduction

CHAPTER 1: Software Architecture

1.1 Run-time Abstraction

1.2 Elements

1.3 Configurations

1.4 Properties

1.5 Styles

1.6 Patterns and Pattern Languages

1.7 Views

1.8 Related Work

1.9 Summary

CHAPTER 2: Network-based Application Architectures

2.1 Scope

2.2 Evaluating the Design of Application Architectures

2.3 Architectural Properties of Key Interest

2.4 Summary

CHAPTER 3: Network-based Architectural Styles

3.1 Classification Methodology

3.2 Data-flow Styles

3.3 Replication Styles

3.4 Hierarchical Styles

3.5 Mobile Code Styles

3.6 Peer-to-Peer Styles

3.7 Limitations

3.8 Related Work

3.9 Summary

CHAPTER 4: Designing the Web Architecture: Problems and Insights

4.1 WWW Application Domain Requirements

4.2 Problem

4.3 Approach

4.4 Summary

CHAPTER 5: Representational State Transfer (REST)

5.1 Deriving REST

5.2 REST Architectural Elements

5.3 REST Architectural Views

5.4 Related Work

5.5 Summary

CHAPTER 6: Experience and Evaluation

6.1 Standardizing the Web

6.2 REST Applied to URI

6.3 REST Applied to HTTP

6.4 Technology Transfer

6.5 Architectural Lessons

6.6 Summary

Conclusions

References

List of Figures

Figure 5-1. Null Style

Figure 5-2. Client-Server

Figure 5-3. Client-Stateless-Server

Figure 5-4. Client-Cache-Stateless-Server

Figure 5-5. Early WWW Architecture Diagram

Figure 5-6. Uniform-Client-Cache-Stateless-Server

Figure 5-7. Uniform-Layered-Client-Cache-Stateless-Server

Figure 5-8. REST

Figure 5-9. REST Derivation by Style Constraints

Figure 5-10. Process View of a REST-based Architecture

List of Tables

Table 3-1. Evaluation of Data-flow Styles for Network-based Hypermedia

Table 3-2. Evaluation of Replication Styles for Network-based Hypermedia

Table 3-3. Evaluation of Hierarchical Styles for Network-based Hypermedia

Table 3-4. Evaluation of Mobile Code Styles for Network-based Hypermedia

Table 3-5. Evaluation of Peer-to-Peer Styles for Network-based Hypermedia

Table 3-6. Evaluation Summary

Table 5-1. REST Data Elements

Table 5-2. REST Connectors

Table 5-3. REST Components

Big O Notation is based on complexity theory and is something engineers and architects should know about do determine complexity and orders of magnitude in their data and scalability formal blueprints. Whenever you use any algorithm or port a formal function into code, math and reducing the orders of magnitude is what separates the fast from really fast.

Optimization can be evil, but solid base starting points are desired. Many times formal knowledge can be as needed as logical or physical separation and understanding service and standards format layering in your applications for the best evolution and versioning as well as performance. Formal engineering is what is separating companies like Google from the pack. Do you do formal?

Orders of common functions

Here is a list of classes of functions that are commonly encountered when analyzing algorithms. All of these are as n increases to infinity. The slower-growing functions are listed first. c is an arbitrary constant.

Notation	Name	Example
	constant	Determining if a number is even or odd
	inverse Ackermann	Amortized time per operation when using a disjoint-set (union-find) data structure
	iterated logarithmic	The find algorithm of Hopcroft and Ullman on a disjoint set
	logarithmic	Finding an item in a sorted list with the binary search algorithm
	polylogarithmic	Deciding if n is prime with the AKS primality test
	fractional power	searching in a kd-tree
	linear	Finding an item in an unsorted list
	linearithmic, loglinear, or quasilinear	Sorting a list with heapsort, computing a FFT
	quadratic	Sorting a list with insertion sort, computing a DFT
	polynomial, sometimes called algebraic	Finding the shortest path on a weighted digraph with the Floyd-Warshall algorithm
	exponential, sometimes called geometric	Finding the (exact) solution to the traveling salesman problem (under the assumption that P ≠ NP)
	factorial, sometimes called combinatorial	Determining if two logical statements are equivalent[1], traveling salesman problem, or any other NP-complete problem via brute-force search, finding the determinant of a matrix with expansion by minors
	n to the n
	double exponential	Finding a complete set of associative-commutative unifiers[2]

Not as common, but even larger growth is possible, such as the single-valued version of the Ackermann function, A(n,n). Conversely, extremely slowly-growing functions such as the inverse of this function, often denoted α(n), are possible. Although unbounded, these functions are often regarded as being constant factors for all practical purposes.

Code generation is not ORM (Object Relational Mapping). ORM is not code generation.

These are two separate ideas. ORM is part-of code generation but code generation is super to ORM.

I get in discussions with people that are strongly against ORM mostly due in part to Jeff Atwood’s post that ORM is vietnam. Yes it can be, and ORM is only for highly tailored teams and projects and creates bulk and uncontrollable code bases. BUT, code generation is valuable and here to stay.

Code generation can be a templating system that outputs code that exactly is the way you would write it and generate unit tests, db field mappings, basic skeletal architecture, maybe a data layer that accesses tables and views or any one of those things from a custom, open source, standard or commercial templating system.

Code generation can also be macros, db migration processes (SSPI or DTS or PL-SQL or n), adding a new file in yoru IDE (VS.NET/Eclipse/FD templates), configuration files, refactoring tools, and many other things. Code generation is a part of life for a programmer or engineer. In fact if you dont’ start getting a handle on the code generation systems that are evolving then you will be that much more without a solution when platforms advance.

Code generation can also be team building because many times people against code generation are hand coders. This is fine and this works great for one programmer. When you add programmer++ to any single team all of a sudden “styles” come into play. Code generation and basic framework or API code structures should be similar in a team environment so that others have a base layer of knowledge they can get up to speed on. Code generation brings the style battles and architecture to the forefront on how code should look in an organization. As you can imagine when you give 50 architects or developers the lead, you will get 50 different was of doing things, some good, some bad. Code generation ensures at least a basic structure of code and apis that can be used. Team integration is hard, code generation usually goes hand in hand with this if it is as small as new file templates in an IDE or a macro all the way to entire api framework generators.

It is important that code within the same project look and act the same. Same styles, same conventions, same architecture. One way of settling this is having code generation that everyone agree upon that can help at least structure projects the same, even if implementation and behind the API layer things are like the wild wild west.

Code Generation > ORM

Code Generation is usually guilty by association. We are hoping to change the perception, but again code generation is really only needed when you get beyond the single programmer mindset, or when you start to make a product family or open source.

Code Generation != ORM, Code Generation IS for the Code Generation

XML is railed against plenty these days for being too verbose and leads to massive config invasions in your codez. But it deserves due respect for what it did.

What did it do you say?

Well, there was a time when data services rarely existed, connecting to trading partners or business partners was almost impossible. Connecting with partners directly to their RDBMS which is poor coupling and is not as message based as services.

Before XML was accepted it was a pipe-delimited, tab delimited, column delimited, ini file, proprietary binary serialization, locked down, non sharing, no service type world. It was the dark ages of data sharing. Hate on XML all you want, XML opened the doors.

Then comes XML, the executives and CTO magazines flooded with the term XML and large budgets signed on the word alone. But was it all hype or did it do something amazing? XML Amazing you say? With XML it was so simple it gave people no excuse not to open up information. A flawless victory on data nazi attitude. Is it the best, no, but it did what was necessary. We would not have the service based systems we have now of even JSON or other more micro formats at all if it weren’t for XML. Both HTML and XHTML and XML are all responsible (javascript as well and MIME) for delivering the simplistic base platform which all programmers can write to to instantly make their apps standard, the web and services that live on them.

After XML… Yes, XML did the amazing… It freed data into services. The web was also instrumental in this effort itself but when systems started working so closely together the exchange and mapping of data quickly became troublesome. Before web services emerged, client/server, remoting, RPC or other more closely coupled communication connections ruled the day. XML with web services helped to push the service model in addition to other technologies such as SOAP bloated but XMLRPC, REST, JSON, have emerged in stronger force or late because they are better iterations and less enterprise-y and simpler and more compact but I still believe that XML was in large part a tool that made data so simple to share that the capabilities and costs came down when people wanted to expose this data.

XML deserves to be a baseplane technology and is used where appropriate in baseplane tools and toolkits.

XML is recently 10 years old, seems like the average for standards to truly take hold and influence. Same with CSS, XHTML, the DHTML that later became AJAX and javascript kits of today. They are all stepping platforms.

baseplane: In software development, a set of tools, systems, patterns and designs that allow a system to be easily transferred to many back ends, services or front ends using standards, patterns and ideally non platform specific tools. Typically the baseplane includes both open standards and market standards based on industry usage. A baseplane may also be a way to commonize output to allow better designer and developer production.

A baseplane is a word I termed to describe the current, most technologically advanced set of tools and patterns that are usable across all major programming platforms.

The idea is that a company or programmer is sometimes held hostage by a particular platform or developer mindshare. People loving a good competition boast about platforms over other platforms and how one is better than the other. It is all fun and games but it doesn’t really give you the ‘best’ patterns and solutions. By patterns I mean general patterns not design patterns specifically for OO programming.

The ideal situation is where software is built semantically and from user perspectives with simplified enterprise entities and collections that perform top notch in a data store, no matter the platform or the language used to create it.

That is where true solutions begin, when companies and individuals can use the best platform or framework no matter their legion. A baseplane is a way to create systems that work well in many systems.

For instance JSON is a great example, this allows a layer to make back ends any language and then the front end any presentation from apps, to web to flash to whatever.

There will be more on this but the tools on this site all have this in mind.

It is a well known fact that humans are thrown into an abyss without much information given or input, they are simply thrown in and latch onto platforms and something to start relative understanding. This is why so many belief systems, points of view and general human pathing exists (more on pathing in future philosophy topics), when it is all trial and error it what works might be different for everybody.

So programmers or creators are the same, once they are thrown into the software world abyss, especially without theory or computer science, the programmer usually latches onto the closest, most low-entry-bar technology/platform/company/language for their use (whatever provides the cash money – you can apply this to any market/industry really).

Once that skill is mastered, they reach to others in the same space, they reach to some standards that mix with other platforms. Then, eventually, they reach the walls of the platform just like on the Truman Show (maybe a 2-5 year run), they realize it is a box not a baseplane. Once the abstraction of the platform to the solution and design inputs and outputs as a whole it becomes clear this is a power of 10 abstraction removed from a programmer stuck in platform-like religious battles, still latching on to a particular platform or language over general solution making. The programmer that rises above all this is the true master of the skill or talent if you want to call it, this is when they become an engineer.

Programmers are the ones doing the hard work to make it easier. As a programmer you have already committed to doing the hard work.

Consuming systems as the input and simplifying them as the output, the ultimate goal of a programmer.

Oh, and all programmers eventually become philosophers, it is a side effect that is spawned from an input of understanding users. Or in particular, how the human works and interacts with your system through HCI – Human Computer Interaction and the interface for which they do so.

Power of Ten Reference