Draft Disclaimer: Please note that this article is currently in draft form and may undergo revisions before final publication. The content, including information, opinions, and recommendations, is subject to change and may not represent the final version. We appreciate your understanding and patience as we work to refine and improve the quality of this article. Your feedback is valuable in shaping the final release.
Language Mismatch Disclaimer: Please be aware that the language of this article may not match the language settings of your browser or device.
Do you want to read articles in English instead ?
Securing your apps
In app security
- rate limiting both web and api
- recaptcha to protect against automated form submission
- monitor charge, set alarm on concurrent request, db queries
- aggregate by user to spot anomalies
- more edge case handling, failsafe code
Infrastructure security
- keys of the kingdom
- check dependencies vulns automatically
- npm audit
- composer audit
- tool from symphony se
- automate patches install
- dependabot auto merge CI action
- for npm and composer deps
- ssl pinning
- scan request for malicious intent
Networking
Can be included in the infrastructure
- fail2ban or ufw for port scanning, brute forcing
Best Practices
- all the above should protect against denial of service, server data scraping, financial impact (abuse of google map api, aws, all non free third parties services utilized on your app)
- security at heart
- predict and protect vs detect and respond
- security at the networking level
- security at the application level
- multiple accounts
- many requests
- ratelimiting comes in handy
- non human account - verification comes in handy
- suspicious action should block account - harmful speech - abuse
- security should be seen as a whole not separated
- example of email spam triggering alert level 1, web scrapper triggering alert level 1, multiple request triggering alert level 1 but all together that should trigger level 3 of a threat
- security practices
- block hosts that tries to access services not offered over 3 times
- block hoss that tries to access services offered with wrong parameters/credentials
- actions monitoring - ie login from different machine, multiple regions - more than usual amount of action over time - attempt to access unauthorized services/actions
Conclusion
it’s so easy to point at others’ faults. When that same eagerness is use to reflect on ours with the perspective of improving would be so beneficial. I did a review of a fin tech app that has launched recently (not that they solicited for my expert opinion). They made mistakes that were obvious to me. They have been notified of course after someone put me in touch with the founder. I will publish the report once they fix the said issues. It turns out I was making few of those mistakes myself on my apps too. Not putting captcha on open forms where users do not need to be logged in (ie contact, registration) So I took my own advice and implemented it. Didn’t take long actually. What was interesting to me is how quick I was to spot it when it was someone else mistake. Humbling experience.