You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orders trigger significant computation. It would be easy to mount a DoS attack by submitting a lot of orders.
Order notification could become a spam bot if emails are not verified.
Malicious users could cancel other users' orders.
Possible responses (numbers do not correspond to risk enumeration):
Have a user authorization system. Don't let users modify (or even perhaps see) sensitive resources owned by other users, e.g., orders. This would cover all risks.
Throttle orders by originating IP address?
Obfuscate order ids to prevent spoofing of order URLs for cancellation?
That would only work if we did not expose the /orders list resource. And that resource is necessary if the app(s) are to be able to recover from various fails (by, amongst other things, reloading lists of orders issued).
Maybe we can require the user to provide their email and list only orders notified to that email. This would still leave the door ajar to malicious users who know other users' emails, but it is less of an opening.
Security risks:
Possible responses (numbers do not correspond to risk enumeration):
Have a user authorization system. Don't let users modify (or even perhaps see) sensitive resources owned by other users, e.g., orders. This would cover all risks.
Throttle orders by originating IP address?
Obfuscate order ids to prevent spoofing of order URLs for cancellation?
/orders
list resource. And that resource is necessary if the app(s) are to be able to recover from various fails (by, amongst other things, reloading lists of orders issued).See some parts of this discussion for a bit more on this.
More research and discussion needed.
The text was updated successfully, but these errors were encountered: