| Except that a trade api should never be 100kloc. The key to securing services like this is to drastically reduce attack surfaces. A lot can be gained just from splitting the API up into multiple services and multiple levels. The HTTP api that's accessible over the internet would not be able to connect to the database, instead it would perform its actions by making requests to multiple services, every service having the absolute minimum api endpoints required. A user creation service. A user details service. An authentication service. A trade submission service. A trades reading service. Each of these servers would run on different VM's, if the money is there, make that different hardware. Where possible the data would be split into different databases, a trade database, a users database, a wallets database. The different services would have their own login credentials to those databases, would not be able to even connect to databases they don't need, and their credentials on those databases would only allow them to execute the queries that they need to do. (If a database you use does not allow for fine enough access control the service would access the database through a middleware that does.) If that seems like a lot of work, I bet you there are security professionals reading this laughing at it knowing this is just a sane basic architecture, and that I'm a rookie and they'd do a dozen more stuff. My point is just: Even if there's a 100kloc in your system, it doesn't mean it's impossible to secure. Even a 100kloc system will have a limited attack surface that can be divided, and controlled. |