3 ms·
the last major piece of software i worked on was a server that performed equity trades on some major european stock exchanges (london, paris, milan, frankfurt)
by zabzonk 4y ago
the last major piece of software i worked on was a server that performed equity trades on some major european stock exchanges (london, paris, milan, frankfurt) and with some third-party brokers. the software ran on machines in the bank's own datacenter and could not be accessed from outside (it didn't take incoming requests from anything except the bank's internal physical network, though it did take fills from an exchange in response to a trade). the server had to comply with the rules of the various exchanges, else the trades would not go through.
so, my question is, where do i need to consider "security" in this situation, which is common in all the banks i've worked for?
- xg15 4y ago> it didn't take incoming requests from anything except the bank's internal physical network I hope, it's still at least checking CORS headers, otherwise it might be vulnerable to a drive-by attack [1]. (At least if some device on the local network runs an older browser which does not implement CORS Private Network Access headers yet [2]) [1] https://wicg.github.io/private-network-access/#biblio-drive-by-pharming https://wicg.github.io/private-network-access/#biblio-drive-... [2] https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/
- watwut 4y agoThat sort of stuff is usually dealt with at application server or somewhere around that level. The developer working on rules themselves is never encountering http requests themselves. Or very rarely. That is how actual secure coding is achieved - by dealing with headers and requests in one standard well tested place. Actual new development is separated, so there is no need for someone working on trading engine to deal also with cors
- zabzonk 4y agodidn't use http