I placed this title, Data Flow Diagram (DFD), at the beginning for a reason; because it's my favorite section and I use it as a reference in the ATM document. The DFD will allow us to gain a better understanding of the application by providing a visual representation of the different pieces of the web application. The focus of the DFD is on how data moves through the application from the user until it reaches its final destination (for example, a database or filesystem). Generally, I use the architecture document that you already received during the Architecture phase, from the project team, to develop the DFD (the architecture document should contain the architecture diagram of the application):

As you can see from the preceding diagram, there are a number of shapes that the application security community uses when designing a DFD:

• External Entity: This shape represents the entity that interacts with an application (for example, customer, employee, manager, and so on):

• Privilege boundary: The privilege boundary shape is used to represent the change of privilege levels as the data flows through different areas in the system. It is represented by a red dotted line (see the preceding DFD example). 

Also, I use the dotted rectangle shape to group the boundary for a group of items (for example, inside the company boundary).

• Data Flow: The data flow shape represents data movement within the application. The direction of the data movement is represented by the arrows:

• Subprocess: This shape is used to present a collection of subprocesses. You use this one when you know that the task can be broken down into its subprocesses in another DFD:

• Process: The process shape represents a piece that handles data within the application. In practice, I use the subprocess shape most of the time, but that's me and you're not obliged to follow my methodology (it's nice to sometimes step outside the norms and not be a victim of the shapes):

• Data Store: The data store's shape is used to represent locations where data is stored (for example, file and database). I usually use the following shape:

I also use this shape (OWASP style):

Here are some rules that I learned by myself in order to have a successful DFD diagram:

• Keep it simple (don't add too many details), but don't miss the important details either
• Be artistic and don't be a slave to the design that the community is using, you can have your own, too (discuss this with your manager if you have one)
• The diagram should be self-explanatory, even if you look at it after a year (or more)