This is specifically about when to develop and implement code for authentication and authorization. I do not mean things the developer should be aware of such as exploits or using Prepared Statements for SQL Injection, and so on. These should be axiomatic for the developer.

What I mean is when in your development cycle do you build in the Authentication and Authorization "system/membership/whatever you want to call it"? Do you do it as you're going along, maybe you just turn it off or make yourself an admin, so you can run your code? Whether it is "Role Based" or "Activity Based" or something else I don't think should matter for this question. I might know what security I want to use, the system, architecture, etc., but when in the SDLC do I put that system in the actual code (whether I wrote it or it is some plugin)?

I do not mean the database. Only the application and that with Usernames and Passwords. I do not mean in my mind. I mean when you sit down to start typing your tests or however it is you write your software. When do I actually start typing the security stuff in? Before I do anything, during it, after it? All three+?

Side question, would TDD necessitate I do security as I go along?

There were promising question titles, but not the answer(s) I was looking for. It feels like it would get in the way of making things work. But I don't want it to be an afterthought either.

I put the word compile in the title to emphasize what I meant by "when."

Edit: For example, do I add this as I do this:

 // Create a PrincipalPermission object.
            PrincipalPermission MyPermission = 
                new PrincipalPermission("MyUser", "Administrator");


[AttributeUsage(AttributeTargets.Field, AllowMultiple=false)]



I am not asking for which kind of security I should implement. There is no way for you to know that. I am only asking the when it should be typed in.

(Code I copied from MS sites)

5 Answers 5


If you follow an agile process, the answer is "when you need it". Most likely it will be relatively late in the development cycle. The reason is you want to deliver actually useful core functionality as early as possible so you can get feedback from product owner and stakeholders. A security infrastructure without any functionality cannot really be evaluated, but core functionality without security can be evaluated and get useful feedback.

If you follow a classic waterfall model, you will develop security early in the process since it is a fundamental piece of infrastructure which business logic is built on top of. But in agile, infrastructure is usually postponed until it is absolutely needed.

This does not mean security is neglected and treated as an afterthought, it is just a question of prioritizing tasks to reduce overall risk for the project.

  • 1
    But in agile, infrastructure is usually postponed until it is absolutely needed. -- That seems... remarkably short-sighted. Jul 27, 2017 at 21:37
  • 1
    @RobertHarvey it can seem that way. But what it really means is that you never let decisions about your security design spread. You design so that most of your system will never know how you designed your security. Do that and you can put it off until you need it. When your security needs change you can change them without having to throw away most of your system. Procrastination lets you design your security only when you know what it really needs to be. Write the rest of your code so that ANY security could be added and you don't have to know now. Jul 27, 2017 at 23:02
  • 1
    @JeffO: The question is not "why wait", the question is which feature provides the most value to develop next. You can say "why wait" about every module you know is required, but you cannot do everything at the same time, so you have to choose.
    – JacquesB
    Jul 28, 2017 at 7:22
  • 1
    @Evan: If you decide login is the most important use case to get early feedback on, then you start with the login page.
    – JacquesB
    Jul 28, 2017 at 9:18
  • 1
    @JacquesB - Permanent storage is usually a requirement of many applications, but you can write a lot of code, modify the code based on changing requirements, but that doesn't mean I have to build the database on day one. That's a decision that can be put off until much later and benefits from having as many of the requirments baked-in as possible.
    – JeffO
    Aug 2, 2017 at 14:44

Security (in general) is part of the functionality of your application. It is not an add-on. Security and access control affect whether other functions can be performed and on what data. This means it is also an important facet of your unit testing and component testing. It cannot be deferred until system integration -- it will be too late then.

As for PrincipalPermission objects and friends, you may want to specify an abstract permission such as PermissionToAddCustomer, PermissionToModifyCustomer, etc. Each of these abstract permissions would then be bound to a domain of interest to get concrete permissions.

Your unit tests for, let's say, adding a customer might look like (pseudo-code):


and so on. The first test in the list is probably the only one you think to start with. You will need to have tests that explore the combinations and permutations of the permissions model you implement.

The usual consequence of adding your security and access model late in the game is that you don't have those variations in your unit tests, and you do all of your testing only with "AllPermissions". This leads to large security holes.


Security mechanisms should be put in place as early as is practical, for the following reasons:

  1. Proper security can affect the design of nearly anything in your site. For example, if you have role-based object access, it may affect how you pass object identifiers in your HTTP requests (e.g. direct object versus indirect object references); it may affect whether a particular page accepts a POST or a GET; it may affect how you divide up workflow steps in the UX (e.g. to prevent a user from attempting an activity that he will not be able to complete); it may limit your use of iFrames; etc. In order to prove your designs you will need to be able to test with at least two roles and you will need to be able to exercise the site in authentication vs. unauthenticated mode.

  2. Your security designs and implementation may need external review, e.g. if you are attempting PCI/FDIC/ISO/FISMA compliance. The sooner you get the stuff put together, the sooner you can get the review process completed. Until it is done, your PM will have to keep a risk item on the status reports since the impact of a failed review could be serious.

  3. Security mechanisms need to be verified through App Scan and PEN testing, which are not trivial exercises. If you build authentication/authorization early, you can increase project parallelism. Other features are not likely to get this level of scrutiny so they are better candidates to put off till later.

  4. There are many features that could depend on security context, everything from rendering the menu system to recording audit records for user activity. If you change the security systems later, you could end up invalidating a lot of QA.

  5. Back end services may require bits and pieces from your authentication/authorization context, e.g. if you are using context propagation.

On the other hand, if your authentication system is very complex, or relies on third parties (e.g. if you accept SAML or some sort of bearer token from a federated authentication system), you may be in a bind, since you don't want to have to wait for dependencies before building the meat of your site. In that situation you may want to write a back door that creates a security context that your site can use. A back door can be as simple as a bookmarkable URL that lets you specify a user ID but doesn't require any password or other validation. Your main code should still use the "final" interface for accessing security context, but the creation and teardown of the security context would be simplified, possibly with items hardcoded, to allow you to proceed.

Putting it off to the end is not a great idea, unless your site has very lax security requirements, e.g. it is for sharing baby photos and not for sending payments or completing purchases.

  • If QA locks you into a particular security system it's badly designed QA. Jul 28, 2017 at 0:21
  • 1
    I am not sure you understood my post. If you modify something that affects a bunch of pages that have already been tested, you may need to retest those pages, regardless of how you design your QA.
    – John Wu
    Jul 28, 2017 at 0:53
  • If retesting those pages is painful enough that you wont modify something you're doing testing wrong. Jul 28, 2017 at 1:55
  • Agreed. That being said, it is usually a good idea to consider the impact of retesting when planning, with an eye to keeping it to a minimum.
    – John Wu
    Jul 28, 2017 at 16:30
  • My idea of keeping testing to a minimum is never letting QA perform a manual test more than twice. Once to discover the defect. Once to get the test automated so the manual test can be discarded. I've seen projects die under the weight of manual tests. Never again. QA should not be a repetitive job. QA should be a creative job. Jul 28, 2017 at 18:34

The sooner you include authentication module into your code, better it is. The reason being that the consumer of your API can include and test it. Otherwise it could give you false impression that everything is working fine whereas technically it is not.

  • I don't have an API in mind here but good to think about.
    – johnny
    Jul 27, 2017 at 23:00

It varies for different projects and companies. If you know what security, authorization and authentication you're going to need (often this isn't very complicated), then you build it sooner rather than later.

However, if you think there are other design decisions that could impact how it's implemented, you may want to wait. Some clients want a very sophisticated system until they find out they're going to have a lot of administration to contend with, so they cut back. Other times, you may not know how parts of the application are going to be implemented. A change to them could impact authorization.

Something like having sales divisions in a Customer Relationship Management (CRM) can alter the requirements during the development process as the client gets a better understanding about what they want. Can sales people in one division see clients in the other? Different lines of business may want to cross-sell to different territories, so the answer would be yes. Does reassignment need to be a simple and easy process? Maybe not if it doesn't happen often.

Usually you put off all decisions to as late as possible. You can develop a lot of software and business logic before you even pick a database or maybe you don't need one at all. Security decisions are the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.