Alice and Bob Learn Application Security by Tanya Janca

Alice & Bob Learn Application Security



Tanya Janca






I dedicate this book to my tireless cheering squad: Lexy, Matteus, Ash, and Vane. Your constant support, encouragement, and celebration of each milestone kept me going. Also, thank you for not judging me for how much ice cream I ate during my editing.

About the Author

Tanya Janca, also known as SheHacksPurple, is the founder of We Hack Purple, an online learning academy, community, and podcast that revolves around teaching everyone to create secure software. She is also the co-founder of WoSEC: Women of Security, is a project leader for OWASP DevSlop, and is a chapter leader for OWASP Victoria. Tanya has been coding and working in IT for over twenty years, has won numerous awards, and has been everywhere from startups to public service to tech giants (Microsoft, Adobe, and Nokia). She has worn many hats: startup founder, pentester, CISO, AppSec Engineer, and software developer. She is an award-winning public speaker, active blogger and streamer, and has delivered hundreds of talks and trainings on six continents. She values diversity, inclusion, and kindness, which shines through in her countless initiatives.

About the Technical Editors

Dominique Righetto started his career in software development before moving, eight years later, to the security side while continuing to live on the border between the two worlds. Dominique is strongly interested in the offensive and defensive aspects of application security. When he moved into the field of security, his objective was (and always has been) to help development teams integrate security into their projects, using a pragmatic point of view. Dominique has been an active member of the OWASP foundation since 2011, where he contributes to different projects, mainly those concerning the web and mobile domain (his domains specialization). Adept at the open source philosophy, he contributes to various open source projects in his spare time. His homepage is

Elie Saad is an experienced information security officer working in the banking industry. He leads and contributes to various standardization initiatives at OWASP and regularly publishes articles on the subject. His main drive is to provide guidance for software developers to own and champion security. He has presented several local talks to bring security closer to newcomers and has been a podcast guest on Security Journey, raising the awareness of various AppSec projects. He is an advocate for breaking down the fragmented culture in the AppSec world. In addition, Elie enjoys taking time to appreciate the simpler things in life, a nice breather in the mountains, and a tasteful glass of whiskey (single malt, of course). You can find him on Twitter (@7hunderSon) and on GitHub (thunderson). You can also reach him via email at


I would like to thank Jim Minatel, my publisher, for helping me decide that I was ready to write a book, and what type of book to write. Thank you, Adaobi Obi Tulton, my editor, for your endless patience, guidance, and very-helpful-check-ins that kept me on track for the largest project of my professional life. Thank you to Dominique Righetto and Elie Saad, my technical editors. I could never afford to pay you for how hard you both worked to ensure I did not make any grave technical errors. I do not have words to convey my appreciation for your time, expertise, and support. Thank you all for coming on this journey with me.


Why application security? Why should you read this book? Why is security important? Why is it so hard?

If you have picked up this book, you likely already know the answer to this question. You have seen the headlines of companies that have been “hacked,” data breached, identities stolen, businesses and lives ruined. However, you may not be aware that the number-one reason for data breaches is insecure software, causing between 26% and 40% of leaked and stolen records (Verizon Breach Report, 2019).1 Yet when we look at the budgets of most companies, the amount allocated toward ensuring their software is secure is usually much, much lower than that.

Most organizations at this point are highly skilled at protecting their network perimeter (with firewalls), enterprise security (blocking malware and not allowing admin rights for most users), and physical security (badging in and out of secure areas). That said, reliably creating secure software is still an elusive goal for most organizations today. Why?

Right now, universities and colleges are teaching students how to code, but not teaching them how to ensure the code they write is secure, nor are they teaching them even the basics of information security. Most post-secondary programs that do cover security just barely touch upon application security, concentrating instead on identity, network security, and infrastructure.

Imagine if someone went to school to become an electrician but they never learned about safety. Houses would catch fire from time to time because the electricians wouldn't know how to ensure the work that they did was safe. Allowing engineering and computer science students to graduate with inadequate security training is equally dangerous, as they create banking software, software that runs pacemakers, software that safeguards government secrets, and so much more that our society depends on.

This is one part of the problem.

Another part of the problem is that (English-language) training is generally extremely expensive, making it unobtainable for many. There is also no clear career path or training program that a person can take to become a secure coder, security architect, incident responder, or application security engineer. Most people end up with on-the-job training, which means that each of us has a completely different idea of how to do things, with varying results.

Adding to this problem is how profitable it is to commit crimes on the internet, and with attribution (figuring out who did the crime) being so difficult, there are many, many threats facing any application hosted on the internet. The more valuable the system or the data within it, the more threats it will face.

The last part of this equation is that application security is quite difficult. Unlike infrastructure security, where each version of Microsoft Windows Server 2008 R2 PS2 is exactly the same, each piece of custom software is a snowflake; unique by design. When you build a deck out of wood in your backyard and you go to the hardware store to buy a 2x4 that is 8 feet long, it will be the same in every store you go to, meaning you can make safe assumptions and calculations. With software this is almost never the case; you must never make any assumptions and you must verify every fact. This means brute-force memorization, automated tools, and other one-size-fits-all solutions rarely work. And that makes application security, as a field, very challenging.

Pushing Left

If you look at the System Development Life Cycle (SDLC) in Figure I-1, you see the various phases moving toward the right of the page. Requirements come before Design, which comes before Coding. Whether you are doing Agile, Waterfall, DevOps, or any other software development methodology, you always need to know what you are building (requirements), make a plan (design), build it (coding), verifying it does all that it should do, and nothing more (testing), then release and maintain it (deployment).

Schematic illustration of the System Development Life Cycle.

Figure I-1: System Development Life Cycle (SDLC)

Often security activities start in the release or testing phases, far to the right, and quite late in the project. The problem with this is that the later in the process that you fix a flaw (design problem) or a bug (implementation problem), the more it costs and the harder it is to do.

Let me explain this a different way. Imagine Alice and Bob are building a house. They have saved for this project for years, and the contractors are putting the finishing touches on it by putting up wallpaper and adding handles on the cupboards. Alice turns to Bob and says, “Honey, we have 2 children but only one bathroom! How is this going to work?” If they tell the contractors to stop working, the house won't be finished on time. If they ask them to add a second bathroom, where will it go? How much will it cost? Finding out this late in their project would be disastrous. However, if they had figured this out in the requirements phase or during the design phase it would have been easy to add more bathrooms, for very little cost. The same is true for solving security problems.

This is where “shifting left” comes into play: the earlier you can start doing security activities during a software development project, the better the results will be. The arrows in Figure I-2 show a progression of starting security earlier and earlier in your projects. We will discuss later on what these activities are.

Schematic illustration of the Shifting or Pushing Left.

Figure I-2: Shifting/Pushing Left

About This Book

This book will teach you the foundations of application security (AppSec for short); that is, how to create secure software. This book is for software developers, information security professionals wanting to know more about the security of software, and anyone who wants to work in the field of application security (which includes penetration testing, aka “ethical hacking”).

If you are a software developer, it is your job to make the most secure software that you know how to make. Your responsibility here cannot be understated; there are hundreds of programmers for every AppSec engineer in the field, and we cannot do it without you. Reading this book is the first step on the right path. After you've read it, you should know enough to make secure software and know where to find answers if you are stuck.

Notes on format: There will be examples of how security issues can potentially affect real users, with the characters Alice and Bob making several appearances throughout the book. You may recall the characters of Alice and Bob from other security examples; they have been being used to simplify complex topics in our industry since the advent of cryptography and encryption.

Out-of-Scope Topics

Brief note on topics that are out of scope for this book: incident response (IR), network monitoring and alerting, cloud security, infrastructure security, network security, security operations, identity and access management (IAM), enterprise security, support, anti-phishing, reverse engineering, code obfuscation, and other advanced defense techniques, as well as every other type of security not listed here. Some of these topics will be touched upon but are in no way covered exhaustively in this book. Please consume additional resources to learn more about these important topics.

The Answer Key

At the end of each chapter are exercises to help you learn and to test your knowledge. There is an answer key at the end of the book; however, it will be incomplete. Many of questions could be an essay, research paper, or online discussion in themselves, while others are personal in nature (only you can answer what roadblocks you may be facing in your workplace). With this in mind, the answer key is made up of answers (when possible), examples (when appropriate), and some skipped questions, left for online discussion.

In the months following the publication of this book, you will be able to stream recorded discussions answering all of the exercise questions online at under the playlist “Alice and Bob Learn Application Security.” You can subscribe to learn about new videos, watch the previous videos, and explore other free content.

You can participate live in the discussions by subscribing to the SheHacksPurple newsletter to receive invitations to the streams (plus a lot of other free content) at

It doesn't cost anything to attend the discussions or watch them afterward, and you can learn a lot by hearing other's opinions, ideas, successes, and failures. Please join us.

Part I
What You Must Know to Write Code Safe Enough to Put on the Internet

In This Part

  • Chapter 1: Security Fundamentals
  • Chapter 2: Security Requirements
  • Chapter 3: Secure Design
  • Chapter 4: Secure Code
  • Chapter 5: Common Pitfalls