Over a million developers have joined DZone.

How To Build More Secure Apps

DZone's Guide to

How To Build More Secure Apps

Keep security in mind from the beginning of the software development lifecycle. Shifting security left in the SDLC is your best bet to prevent vulnerabilities.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

We spoke with 25 IT security executives and asked them what developers needed to keep in mind to make their code and applications secure. Here's what they told us:

Security First

  • Keep security in mind throughout the SDLC. Understand production use cases and the fundamentals of security.
  • There are 100,000 security jobs open. Focus on security by design and you will have a lucrative career. Look at the 25 worst security flaws and ensure that what you are developing does not have any of these. Do deep dive security code reviews to build a safer product. Be an egoless programmer willing to learn and allow others to find faults in your code so you’ll learn.
  • Think about security throughout the SDLC. Code quality, unit testing, code security, linting, static-code analysis.
  • Always have security in mind. Think about if there are security or privacy implications and if the data needs to be encrypted. Do not log PII. Think about how you are authenticating and authorizing. Be vigilant.
  • 1) Begin developing with security in mind from the get go – i.e. when you begin architecting. 2) Educate yourself on what you need to do to develop secure code – Google it, there’s plenty of information on the internet. 3) Implement secure coding practices. 4) Remove crypto keys before going into production. If you take these four steps you’ll significantly reduce the number of attacks.
  • When writing code, make sure it’s secure. A non-functional requirement should be to learn how to write secure code and test it. Everything is connected, making for more attack vectors. Application security testing needs to be incorporated into the SDLC.
  • Security should be the core building block of code. Have an automated code review process. Share best practices.
  • 1) Incorporate security into design reviews. Secure peer code reviews are tremendous learning opportunities for developers to learn. Take the time to do them. 2) Include a suite of security tests. 3) Secure code review increases the level of capability to see the little tricks that take shape. Understand security metrics the same way you understand performance metrics. 4) Be mindful of user sessions or behavior for which you want to evoke security requirements. 5) Don’t grab code from StackOverflow and put it into production. Test it first! Cost of a software bug: $100 when initially coded, $1,500 in QA, $10,000 in production.
  • Security should always be structured into up front application design. From a database perspective, think about permission levels. There will be a significant reduction in maintenance issues downstream if you identify security issues early in the SDLC. There are a lot of great resources online. MongoDB University has a three-to-four week course on security. Put security front and center when designing code.
  • Treat application security like any aspect of code quality. Security tickets have to be worked too. Look for security anti-patterns in your code to catch them earlier.
  • Know that the worst thing that can happen is that your own app will be compromised. Security needs to be part of development from day one. Combine application security and security. Test for security at the same time you are performing all other QA tests. Security needs to be priority one in the development process.

Team Up

  • You cannot develop in isolation. You need peer reviews, third party reviews, and vetting. It’s not complex or expensive. Catch vulnerabilities and data leakage by open sourcing. Code defensively. Think about what’s the worst thing that can happen. Think about how to ensure information cannot be hacked. Look at similar products and their vulnerabilities.
  • Engage security professionals early in the development cycle. Analyze architecture and code. Have teams good at coding working with information security architects to help identify best practices. Have an information security professional on staff, or a consultant on call, to analyze code to ensure it is safe, bug-free, and hack-proof.
  • Embrace the security team and practices the same way you embrace product management. Don’t leave out security, look at it as an enabler that you’ll have a job tomorrow. A lot of security best practices will help get the app to the market faster, safer, and with a longer life. Ask yourself, how secure is the code I’m writing? What vulnerabilities am I injecting? Is it more secure and robust?

Best Practices

  • Always check input parameters regardless of the source. If someone develops an app with fields for the user name, you need to ensure the fields in the app are secure.
  • There is no reason for anything to exist that isn’t encrypted. You must assume all the information you capture is interesting to someone else. Build in security along the way. Make security part of your UX. Think about how you, and others, will interact with your app. Build apps with security embedded.
  • Follow best practices. Know the policies and procedures that will make your apps secure.
  • It can be daunting with so many different languages and frameworks. Most core concepts of application security haven’t changed. Look at the OWASP top 10. Eliminate SQL injection and cross-eyed scripting and you will eliminate a lot of vulnerabilities.
  • Log what you are doing. It’s difficult to understand the activity taking place on your application if you don’t have data from the source. Enable application/device activity logs and share across the organization for instant real-time access. With everything going to microservices, know what’s not secure. Developers want to get microservices out but don’t care if it has an activity log. This makes it easy for anyone to hack because no one knows what’s going on in the chain. Each microservice needs to protect itself so that the end-to-end delivery chain would be more secure. Think about the preventive health of microservices.
  • As you are thinking about new applications, containers and microservices can help reduce the attack surface. Think about what you really need and don’t put more attack vectors out than are necessary. Think about what packages, libraries, and dependencies are required. Run the minimal amount needed to achieve your objective. Don’t treat security as a sequential step or gate after the CI/CD pipeline. Inject security earlier in the process.
  • It’s useful to think about building applications in a compartmentalized way — as fortified units with common and distinct security requirements. In this case, you’re not really increasing the surface area of what needs to be secured, even though there are more things that require security. What you are doing is providing a standardized framework; this best practice allows organizations to provide defense in depth. Think secure microservices, for example. And with API-led connectivity, rather than connecting things point-to-point, every asset now becomes a managed API, making it discoverable through self-service without losing security and control. Each of these application building blocks, designed and built by the teams that need them, will have security best practices built in at the point of design – creating the concept of “security by design.” These application building blocks are connected through APIs, which are standardized, well-defined entry points that are easy to visualize and thus secure.
  • 1) Developers need to bring security testing to the earliest possible stages of development, push security testing in the design and development phases and not right before deployment. Focus on security throughout the development process, beginning when a piece of code is written means it gets tested for quality and security at the same time, providing feedback within minutes or hours. This means code can be released more quickly. 2) Developers also need to keep, create, and maintain a list of recommended software frameworks and components that security teams and developers can and should use. This can give teams a better way to visualize their work, providing a strong support system and giving solid feedback in a short timeframe to keep frameworks up-to-date.

What else do developers need to keep in mind when developing secure code and apps?

Following are the executives that shared their perspectives on this question:

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

security ,container security ,cybersecurity ,devsecops ,appsec

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}