Authored by Gopi Mishra, Principal Architect – Development, WaveMaker, Inc
Enterprises are increasingly using ‘Direct-to-Consumer’ digital initiatives. They are parallelly digitizing their internal processes with increased velocity. These changes bring with them a tide of security threats. From insider threats to exposed marketplaces, there is always a security hazard lurking around the corner–one that can assume mammoth proportions if security doesn’t become an ingrained part of application development. In fact, according to a report by cyber security firm ‘Checkpoint‘, cyberattacks on organizations worldwide jumped by 29% during the first half of 2021 as compared to the same period in the previous year.
Who better to don the mantle of defense than the ‘developer’? After all, when it comes to the security of an application, ‘developers’ are the first line of defense!
A ‘Defense-In-Depth’ approach to security for applications is a layered approach to security. What it essentially means, is that developers should take necessary action to mitigate security risks at every layer, be it the front-end (client), middle-tier, database services, or even the network layer. To do that, developers need to collaborate with various stakeholders: customers, DevOps teams, IT-networking, and the security teams handling the necessary infrastructure.
A developer has to have the same approach while developing secure applications using a low-code platform. WaveMaker comes fortified with SAST tested auto-generated code that is VeracodeTM verified. While developers working with WaveMaker can rest assured of the inherent security of the platform, there are a few best practices that a one can follow while using WaveMaker low-code to develop secure applications.
Embed security using WaveMaker
Developers need to think about security primarily in three areas: Data, Business Logic, and Coding. Data in itself could be static or could be in transmission. Depending on its state, the developer needs to keep an eye out for the following checkpoints:
Data at Rest:
- Ensure that no personally identifiable information is stored at the client-side (in-cache of web application or in device storage of a mobile application)
- For mobile applications, store relevant and critical information in secure elements
- Avoid storing information such as service credentials and connection strings in an accessible file. If stored, ensure that there is a proper authentication and authorization mechanism in place to access these files
- If possible, use rooted/jailbreaking detection for mobile apps.
Cordova provides plugins for the same. This can be added to the application by importing the plugin to the application. Plugins can be imported as described here.
Data in Motion:
Secure data in motion from being intercepted
- Use HTTPS for all calls between the client and the server-side
- Use TLSv1.2
- Ensure that the data between client and server-side is encrypted
- Use updated security certificates that have the latest and secure cipher algorithms
- Ensure validity of certificates. In case, certificate pinning is used on mobile applications ensure that certificates are renewed before expiry and app uploaded to app/play store to avoid apps breaking in production
- Protect API calls with authentication
- Do not include PII data as a part of a GET call
- Use multi-factor authentication
- Have a password policy and validation
- Include input validation as a part of data length, type, and white-listed characters
- Do not include passwords as a part of the ‘Remember Me’ functionality
- Do not provide the reason for the failure of authentication in event of a validation failure
Coding Best practices :
- Do not log sensitive information like passwords
- Include all loggings as a part of the ‘isDebugEnabled’ flag so that they can be disabled in the production
- If ‘Request’ and ‘Response’ are logged or can be logged in debug mode then create filters for sensitive data
- Use the latest versions of third-party plugins that are imported into the application
- Use the latest SDKs/APIs that are tested against vulnerabilities
- Flush out session data during logout
- Error stack trace should not have sensitive information. It is always advisable to add custom messages as error messages rather than simply passing or printing the error stack trace which may have application class/file names or sensitive data.
- WaveMaker is VeracodeTM certified and the auto-generated code is protected against OWASP Top 10 security risks. However, while designing an application the developer should keep these risks in mind and design the application to safeguard it against them (For a greater list of guidelines, follow this OWASP cheat sheet]
Security is an inarguable conclusion
While security best practices can help developers immensely, what is more important, is that they develop a ‘security mindset’. Security must be a priority and not an afterthought. While developing applications using ‘Agile Practices’, security should be a criterion in the ‘Definition of Done’ of user stories. Bigger pieces should be taken up as enabler stories. Regular penetration tests should be performed early in the development stage and should be a part of every sprint release. A security loophole caught early in the game will alleviate future pain points, bring down costs and reduce technical debt.
Being secure is not an option, it is an inarguable conclusion. Developers with a finer sense of security will hold this as their mantra.