Microsoft Azure

Pushing Left, Like a Boss! -- Part 2: Security Requirements

shehackspurple profile image Tanya Janca Updated on ・4 min read

**Previously published on my Medium blog, SheHacksPurple.

In the previous article in this series we discussed why ensuring the security of software is an elusive task; application security is hard to achieve with how the InfoSec and software development industries and education system(s) currently work. We talked about the importance of starting security actives early in the SDLC and formalizing them as part of your process. But what ARE these actives? How do they work, and when do we do what? That, dear reader, is what this article is about.

As you recall from the previous article, the system development life cycle generally looks like the image below:

The System Development Life Cycle - SDLC

System Development Life Cycle (SDLC)

Whether you are doing Agile, Waterfall, or if you have a DevOps culture at your office, you always need to know what you are building (requirements), you need a plan (design), you need to code it (the fun part), testing is obviously a must, and then you release it out into the wild (hopefully you also maintain and monitor it as well, which is all part of the “release” phase). Each one of these phases should involve security activities. Let’s look a little deeper, shall we?


The South Korean side of the South/North Korean DMZ

When writing requirements there will always be security questions, such as; does it contain sensitive or Personally Identifiable (PII) data? Where and how is the data being stored? Will this application be available to the public (Internet) or internally only (intranet)? Does this application perform sensitive or important tasks (such as transferring money, unlocking doors or delivering medicine)? Does this application perform any risky software activities (such as allowing users to upload files or other data)? What level of availability do you need? 99.999% up time? These and many more are the questions that security professionals should be asking when assisting with requirements gathering and analysis.

Here is a list of default security requirements that I would suggest for most software development projects:

  • Encrypt all data at rest (while in the database)
  • Encrypt all data in transit (on its way to and from the user, the database, an API, etc)
  • Trust no one: validate (and sanitize if specialize circumstances apply) all data, even from your own database
  • Encode (and escape if need be) all output
  • Scan all libraries and third-party components for vulnerable components before use, and regularly after use (new vulnerabilities and versions are released all the time). To do this you can use any one of the following tools: OWASP Dependency Check, Snyk, Synopsis, etc.
  • Use all applicable security headers
  • Hash and salt all passwords. Make the salt at least 28 characters.
  • Only allow your site to be accessible via HTTPS. Redirect from HTTP to HTTPS.
  • Ensure you are using the latest version of TLS for encryption (currently 1.2 1.3)
  • Never hardcode anything. Ever.
  • Never put sensitive information in comments, ever. This includes connection strings and passwords.
  • Use all the security features within your framework, for instance session management features or input sanitization functions, never write your own.
  • Use only the latest version of your framework of choice, and keep it up to date
  • If performing a file upload, ensure you are following the advice from OWASP for this highly risky activity. This includes scanning all uploaded files with a scanner such as AssemblyLine, available for free from the Communications Security Establishment of Canada (CSE).
  • Ensure all errors are logged (but not any sensitive information), and if any security errors happen, trigger an alert
  • All sanitization must be performed server-side, using a whitelist (not blacklist) approach
  • Security testing must be performed on your application before being released
  • Threat modelling must be performed on your application before being released
  • Code review (specifically of security functions) must be performed on your application before being released
  • If the application errors it must catch all errors and fail safe or closed (never fail into an unknown state)
  • Specifics on role based authorization
  • Specifics on what authentication methods will be used. Will you use Azure Active Directory? ASP.NET Core Identity? There are many options and it’s a good idea to ensure whatever you choose works with how you are manging identity for your enterprise and/or other apps
  • Only using parameterized queries, never inline SQL
  • Forbid passing variables that are of any importance in the URL. For example, you can pass which language (“en”, “fr”, “sp”) but not your userid, bank account number or anything of any importance within your application or your life
  • Ensure your application enforces least privilege, especially in regards to accessing the database or APIs
  • Minimize your attack surface whenever possible
  • Allow users to cut and paste into the password field, which will allow for use of password managers. Disable password autocomplete features in browsers, to ensure users do not save their passwords into the browser.
  • Disable caching on pages that contain sensitive information
  • Ensure passwords for your application’s users are long, but not necessarily complex. The longer the better; encourage use of passphrases. Do not force users to change their passwords after a certain amount of time, unless a breach is suspected. Verify that new user’s passwords have not previously been in a breach by comparing sha1 hashes using the HaveIBeenPnwed API service.
  • All connection strings, certificates, passwords and secrets must be kept in a secret store, such as Key vault.

Depending upon what your application does, you may want to add more requirements, or remove some. The point of this article is to get you thinking about security while you are writing up your requirements. If developers know from the beginning that they need to adhere to the above requirements, you are already on your way to creating more secure software.

Up next in part 3 we will discuss secure design.

Posted on by:

Microsoft Azure

Any language. Any platform.


Editor guide

I really enjoyed this article thank you. <3

But I would like to discuss something, and I am torn. Shouldn't we be letting the users opt-in to check if their password is compromised? Sending their password to a third-party does invade their privacy.

Especially if it's without the user's consent.

I know that users shouldn't be allowed to have insecure choices.

Again, I'm kinda torn.



Thank you for bringing this up, I clearly didn't explain it well enough. When you send the info to the API to check the password it's the last couple digits of a hash of the password. What that means is that you do a 1-way cryptographic algorithm against the characters of the password, it creates something new that is unrecognizable, then you send part of it to the API. This means at no point have you shared the user's password. But I probably should have said this in the article! Thanks for letting me know this is missing. :-D

But I definitely agree with you; we should never share our user's passwords with anyone, not even our own software developers.



Ah, okay. I did know about how the API works. It was more of a "shouldn't we warn the users' passwords are getting sent to a third-party?".

After all they should have choices how their data is handled.

But another problem out of that is, it could scare them to not use it at all because they don't know the technical details of how it works to make sure no one can figure out their password.

I suppose if the software developers implementing the HaveIBeenOwned service don't understand the security behind it, and how the passwords are compared, I do see that they may be reluctant to use the service. There are also paid services that can do this for you, I believe that 1Password offers such a service. Maybe using a paid service would seem more secure and "legit" than using an open source and free service? This is a good point.

I guess when you're signing up or changing your password/passphrase you could have a little check box saying "Check if your password/passphrase is compromised." that defaults to off.

And of course a information link that first explains to a average user, then more technical details if they're smart enough to understand it.

It seems like a good balance to me. I feel like a lot of people would want to check that box when registering an account. Perhaps that's just me.

Of course this is experimental, which would require research. None of all the services I have seen on the internet implement this.

But I think it would be a good balance.


We (you developer, me security person) need to make a lot of decisions on behalf of our users. Just like a car designer makes many decisions for me that I do not understand, we (software builders) need to make decisions for the users of the software that we create. No users will understand if we give them this choice. It's too much; only professionals would understand, and that's no fair to the average user, who make choose incorrectly. The same would be true if my car manufacturer offered me airbag X or airbag Y, and listed all the reasons to choose one or the other. It would be a waste of time because I'm not a professional car designer/do not have the knowledge to fully understand. Does this make sense? Offering them this choice would just be confusing, not helpful, to any regular (non-IT professional) user visiting a website.

Many services on the internet check for breached passwords all the time, Facebook does it and many, many more. They are doing this to protect their users from a vulnerability called "Credential stuffing", which means attackers using stolen credentials on sites and then stealing or harming the victims. It's happening quite a lot and it's extremely damaging, because many users reuse the same password on many different platforms. Many websites, that we all use, are currently doing this. None of them ask for the user's consent, because they are not sending the password or personal information, it's part of a hash, which is not recognizable to the original password.

If you want to know more about how the partial password hash is passed for the haveibeenpwned.com API, you can read the spec here: haveibeenpwned.com/API/v2

I hope this helps?

Hmm, you're right. I guess we shouldn't be giving users any choices that could potentially allow them to shoot themselves in the foot.

It's really hard being into security and trying to develop solutions for people who don't understand.

Because you have to think and feel like a end-user, when you're really not.

I hear you! I'm a big advocate for usable security features, which means testing with real-live users, not putting someone like me as a tester (because I'm inherently biased, being a security professional).

I am hoping that as the years continue the security industry works harder to make every aspect of security easier and better for the consumer, with the goal of one day having the easiest way to do something will also always be the most-secure way to do it. This is my dream!

I also want to make security easier for Devs. Because right now it is Way. Too. Hard.

Yeah, it is really hard. I think systems should be designed with security from the start. Like you pointed out in your first article. I really wished the ActivityPub protocol was designed with cryptography implemented, but ... of course. It wasn't. And now we have a standardized social network protocol without confidentiality, and authenticated integrity.. which should've been baked in.

Yep. We are biased.

Things are getting better, slowly. We do have Libsodium for cryptography. Still, even then it can be confusing to those who don't understand.

But there isn't really a way to automatically implement secure code with cryptography built into the heart of it.

Only recently I've started thinking about security for the average user. Obviously still having a hard time ...

This Twitter post might interest you, about notifying users:


I like everything on this list bar this item: 'Allow users to cut and paste into the password field, but disable password autocomplete features"

IMO, anything that interferes with password managers or lowers their adoption is a major loss. If you want a password field that can't be attacked computationally, have a debouce and a lockout after 20 attempts.


I agree completely, password managers are absolutely necessary. Allowing for cut and paste will allow Password Managers to function properly, while disabling the browser from performing autocomplete will ensure that users don't accidentally save passwords into their browsers accidentally (unsafe place) and think they are using a Password Manager (safe place to store passwords and other sensitive data). Auto-complete is a browser feature, and disabling it will not interfere with your password manager. :)

I think we agree but perhaps my phrasing was not clear? Should I update the article?

Thank you for your comment!


Great article!

But why is a Browser-Built-In Passwort Manager like Firefox' PW-Manager unsafe? (assuming a master pw is set or the computer is only used by 1 person)

Btw. turning off autocompletion doesn't work in most browsers anyway:

Or did i simply misread your comment?

Browser-Built password management functions are not as secure as as an actual password manager. It is not an overly safe place to keep it. Another reason is that you have no idea who is using your site, nor which computer they are using it from; if someone is in a hostel backpacking across Europe and accidentally says "yes" to the "would you like XYZ browser to save your password?" they have unwittingly saved their password for all the hotel users to use later. Unfortunately we need to design assuming the worst case (public computer, not-technically-savvy user), rather than the best case (for instance you personally, someone who is knowledgable enough to read and understand my blog, is the absolute best case scenario for an app user).

Does this make more sense? Is it helpful?

Also, yes; sadly not all browsers support all of the same features, rules or standards. But we do what we can.

PS Thanks for the really nice comment!


Can't hurt to clarify.

I updated it, thanks! :)