It’s no secret that developing applications becomes even more complex when you look to integrate payment processing. There are literally hundreds of pages of rules and regulations by multiple bodies that you need to follow to ensure your software follows the necessary security protocols and best practices.
DevPro Journal had the opportunity to speak with Nathan Sweaney, a senior security consultant with Secure Ideas, about some of the more common mistakes his company sees concerning payment security in software development. While the following isn’t all you need to worry about if you’re interested in payments integration, it’s a good additional checklist to keep handy.
- Include security from the beginning and in every part of the development lifecycle.
- Don’t get access to data you don’t need and don’t store more than you need.
- Don’t require users to run as admin — the “principle of least privilege.”
- Provide support (and encourage) 2-factor authentication.
- Don’t use default passwords. Require one to be set on install.
- Provide a security implementation guide with realistic configurations. Don’t build a security model on configurations that no one can use in real life.
- Train your developers on secure coding techniques. Most schools don’t teach secure coding, and few developers pursue it.
- Test your software. Lots of options here: Code review, static analysis tools, penetration test, etc.
- Provide a reliable, consistent patching process. It should be as seamless as possible and require minimal action for the merchant.
- Don’t require insecure network configurations. Clearly define what network traffic and firewall rules are necessary to use the app.
- Encrypt network traffic. Even non-sensitive stuff can be encrypted. It’s cheap and easy now.
- Don’t store encrypted passwords. Store salted hashes with an iterative hashing function like pbkdf2.
- Avoid rolling your own. Use standard, accepted libraries whenever possible for encryption, authentication, session management, etc.
- For web apps, keep your whole stack updated (server, language, CMS, libraries).
- Lean on a WAF (web application firewall), don’t stand. WAFs are an emergency patch. You should still do input validation/output encoding – use libraries.
- Proactively limit attacks (logging/alert/IDS/rate limiting/IP-blocks).
- Your API is a target. Don’t assume no one will find it or know how to communicate with it.
