When you’re talking with the client
Regardless of your role in the development process, you’ll want to get as much information directly from the client as you can. When meeting the client, be assertive in pointing out that there cannot be compromises when it comes to security. You should seek answers to the following questions:
What are your client’s requirements when it comes to app security? This isn’t just about your client’s answer to the question. Rather, you should think about keeping your client, the client’s users, and their data safe, and revisit the question as you go.
How will the web application be used? Will it be an intracompany app, or available for free download on Google Play? Note that all use cases need application security, even intranet applications and silly time-wasting games.
Which web application authentication tools will be used? The budget and the composition of the team will depend on the client’s choices (Free, or licensed? Easy, or will training be required?), so this will be important information for your planning stage.
Now to get more specific.
For the business analyst and the UX designer
Don’t protect functions with just an unauthorized (public) URL, even if you think no one could find it. And do not under any circumstances put other users’ data at an unauthorized URL. Use some protection against bots, such as a captcha. If you are not a technically skilled solution architect, choose an external authentication provider. There are enterprise solutions such as ADFS, RSA Link, Evidian, or One Identity, and public ones: OAuth, OpenID, Google, Facebook, Twitter, Amazon, and Microsoft authenticators. Even better, build in multi-factor authentication with one of the many solutions available on the market.
Set up an intrusion detection mechanism (IDS) and mechanisms for detecting and handling suspicious user behavior. Examples are multiple login errors, ID iteration in URLs, blocking known malicious IP access, etc.
You want the IT team to know exactly what errors occur, but not your user. Error messages must not reveal too much information, especially on authenticating or resetting a password. For example, having two separate messages for “the account with this email does not exist” and “password is incorrect” reveals the fact that the user is registered and can be a target of an attack.
For the solutions architect
Periodically check OWASP’s list of top 10 threats. Bad actors change their game from time to time, for obvious reasons, so you should be ready to adapt your product accordingly.
Talk to the client’s IT department. It’s possible that negotiation for your project took place without the participation of the IT department. Especially if they are in charge of the web server, make sure to reach out to them and discuss the following concerns around session management:
What encryption, authentication, and authorization mechanisms are already in use? Ask their suggestions for designing and implementing authentication and authorization between the internal components of the application and the client’s existing systems. You may want or be able to adopt security tools that they already have in use and find out what the company’s data security requirements are.
How to handle and log errors properly. Make sure to hide the error details from the user! How to send the IT team meaningful and clear notifications if something goes wrong. The client’s IT staff might well be the first experts called on in the event of a hack, before you are. This knowledge will help you maintain a secure SDLC (Software Development Life Cycle) management process.
Do not store passwords or sensitive data unless necessary. If it is necessary, do it well! Encrypt your configuration files. Even if you think they’re safe and inaccessible or can’t be found, why not take the extra step? As any security team can tell you, web servers can’t be made entirely invisible.
Automate your deployments to lower the risk of human error. If you’re not already using a pipeline, you might investigate Azure Pipelines.
Never agree to implement any last-minute changes without completing the testing and release process.
Take a look at OWASP’s cheat sheets for the tools and technology you’re using. The Open Web Application Security Project has a mission to improve everyone’s security, so take full advantage of their effort!
For the tester
Test the roles, permissions, and authentication mechanisms on the frontend and in the API. Make sure your application security testing includes the appropriate user level tests, and not at god-mode!
Master both manual and automatic testing tools. The automatic ones will be harder to learn, but they are much more powerful, and you will find vulnerabilities you never thought possible. Run a security audit from time to time. Schedule a meeting with your architect or developer and perform some tests together.
For the developer
Do not trust your framework security features blindly. Think of them as the building blocks of your security architecture, but remember that they can’t entirely eliminate security risks on their own.
Thoroughly validate everything everywhere, especially at the backend.
Authenticate and authorize at the backend, too. Don’t blindly trust whatever comes from the frontend or any other component under your control.
Be careful with the URLs. Make sure not to use integers or other easily iterable identifiers. Don’t use a long random link to a resource on the server in order to share information or files with the user.
Regularly update the packages, libraries, and frameworks that your application will use. The bad actors out there are constantly pushing boundaries to identify vulnerabilities, and this is the best way to be sure to keep up.
For the DevOps Engineer
I’ve saved the highest-level items for last, items that experience has shown to be worth avoiding if you have the training and expertise to do so. If you’re at this level, it’s up to you to be assertive when asked to compromise security guidelines.
Development machines in the cloud should not have public network interfaces turned on.
Your lab domain should have security policies, preferably as strict as the corporate ones.
Domain accounts should not be reused between projects, services, and especially users.
Development machines should have updates installed regularly.
Data from production should not be stored on dev environments (at the very least, anonymize it!).
Passwords should not be stored in the code repository.
Do not share passwords via public channels.
Be suspicious of atypical security-related requests.
Security is an issue for everybody
Application security is a highly complex issue but of ever higher importance as the arms race between DevOps engineers and the world’s bad actors continues. Development teams have the responsibility to consistently work hard to stay current and on top of any security vulnerabilities. This web application security checklist should help get you and your app at least as close to as safe as can be.
