Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Designing & Building Secure Web APIs

1,477 views

Published on

Presented by Vivek Thuravupala, Software Engineer @ Postman in joint meetup in Walmart on 28th April, BLR.

Abstract: We'll talk about the exploding usage of APIs and why security shouldn't be an afterthought when it comes to designing and building APIs. We'll also run through some concrete examples illustrating common pitfalls encountered while design/building.

About the speaker: Vivek builds stuff for the web, and he's been swimming around in various tech ponds since he was a kid. At Postman, he keeps an eye on a bunch of the user-facing products.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Designing & Building Secure Web APIs

  1. 1. April 27, 2018 PRESENTED BY Designing & Building Secure Web APIs Vivek Thuravupala Software Engineer @ Postman
  2. 2. Postman, API Development Environment
  3. 3. Relevance
  4. 4. APIs have been exploding. THOUSANDS OF APIs!
  5. 5. So has API usage. 15B+ 10B+ 7B+ Average Daily API Calls (2016) Source: Programmable Web
  6. 6. The API Lifecycle
  7. 7. Application & API Collation, Transformation... Data-source Database, cache, 3rd Party API, etc. Client API Consumption & Presentation 

  8. 8. Let’s build a GitHub proxy API! Application & API Collation, Transformation... Data-source Database, cache, 3rd Party API, etc. Client API Consumption & Presentation 

  9. 9. Design
  10. 10. ! Why build this API? ! Who is your consumer? ! What can they do with your API? ! Public consumption of private resources ! An open public-facing website ! Fetch activity frequency Planning
  11. 11. ! Why build this API? ! Who is your consumer? ! What can they do with your API? ! Public consumption of private resources ! An open public-facing website ! Fetch activity frequency Planning
  12. 12. ! Public consumption of private resources ! An open public-facing website ! Fetch activity frequency ! Why build this API? ! Who is your consumer? ! What can they do with your API? Planning
  13. 13. Let’s take a quick peek at the GitHub API
  14. 14. TODO: Add API screenshots here
  15. 15. TODO: Add API screenshots here
  16. 16. TODO: Add API screenshots here
  17. 17. Application & API Collation, Transformation... Data-source Database, cache, 3rd Party API, etc. Client API Consumption & Presentation 
 Browser
  18. 18. Security Blanket ! CORS ! HTTPS ! Strict-Transport-Security ! Set-Cookie: SameSite, Secure, HttpOnly ! X-Frame-Options ! Hide Application/Framework Headers Leverage the ecosystem
  19. 19. Security Blanket Reference: MDN Cross-origin Resource Sharing Chrome 4+, Edge 12+, FF 3.5+, IE 10+, Safari 4+ https://www.origin2.com Get all emails https://www.origin1.com XHR/Fetch call
  20. 20. Security Blanket Reference: MDN Cross-origin Resource Sharing https://www.origin2.com https://www.origin1.com XHR/Fetch call Chrome 4+, Edge 12+, FF 3.5+, IE 10+, Safari 4+
  21. 21. Security Blanket Reference: MDN Cross-origin Resource Sharing https://www.origin2.com Access-Control-Allow-Origin: * Access-Control-Allow-Methods: POST https://www.origin1.com XHR/Fetch call OPTIONS POST Chrome 4+, Edge 12+, FF 3.5+, IE 10+, Safari 4+
  22. 22. Cross-origin Resource Sharing Security Blanket ! XMLHttpRequest , Fetch API follow same-origin policy ! Different domain, protocol, or port ! Uses a pre-flight request if necessaryChrome 4+, Edge 12+, FF 3.5+, IE 10+, Safari 4+ Reference: MDN
  23. 23. Security Blanket ! HTTP over TLS ! Enforced on the client ! Does not hide origin/destination IP Chrome 4+, Edge 12+, FF 4+, IE 11, Safari 7+ Reference: MDN HTTPS + HSTS
  24. 24. Security Blanket Reference: MDN HTTPS + HSTS Server https://www.origin1.com XHR/Fetch call, Document request GET, * Strict-Transport-Security max-age: 31536000; includeSubdomains Chrome 4+, Edge 12+, FF 4+, IE 11, Safari 7+
  25. 25. Security Blanket Reference: MDN HTTPS + HSTS Server https://www.origin1.com XHR/Fetch call, Document request HTTP * Chrome 4+, Edge 12+, FF 4+, IE 11, Safari 7+
  26. 26. Security Blanket ! Secure ○ Transmit only over HTTPS ! HttpOnly ○ Disallow access via JS ! SameSite (Chrome, Opera) ○ Useful against CSRF Reference: MDN Set-Cookie Flags Chrome 1+, Edge, FF 3+, IE 9, Safari 5+
  27. 27. Security Blanket ! CSP ! X-XSS-Options ! X-Content-Type-Options ! Referrer-Policy ! Subresource Integrity Just to note, if you’re serving a UI and not just an API. Reference: MDN
  28. 28. Resource Representation ! Decoupled representation ! Sanitized ! Leverage HTTP(s) ○ Keep real-world quirks in mind! Internal vs. External
  29. 29. Design, Mock, Debug ! Do it all in one place Our first priority is to get a usable API.
  30. 30. TODO: Add mock/test screenshots/video herehttps://www.townscript.com/e/walmart-meetup/booking
  31. 31. TODO: Add mock/test screenshots/video here
  32. 32. TODO: Add mock/test screenshots/video herehttps://www.townscript.com/e/walmart-meetup/booking
  33. 33. TODO: Add mock/test screenshots/video here
  34. 34. Versioning A quick word.
  35. 35. Versioning ! Twitter, 3 versions, 5 years ! Google Maps, 3 versions, 8+ years ! GitHub, 3 versions, 6+ years Try to avoid (breaking) versioning
  36. 36. Versioning ! Facebook Graph API ! Versions: ¯_(ツ)_/¯Try to avoid (breaking) versioning
  37. 37. Versioning ! Publishers want to update ASAP ! Consumers want to avoid updating ! Multiple versions = increased attack surface Try to avoid (breaking) versioning
  38. 38. Build
  39. 39. Security Blanket ! Enforce using static code analysis & testing ! Architecture as a forcing function Reference: MDN
  40. 40. Security Blanket ! Lint for security ! Test for security ! Make it harder to be insecure Static code analysis & testing
  41. 41. Security Blanket Architecture as a forcing function ! The larger your team, the more difficult it is to enforce your design
  42. 42. “A forcing function is an aspect of a design that prevents the user from taking an action without consciously considering information relevant to that action.” Security Blanket Reference: Interaction Design Foundation Architecture as a forcing function
  43. 43. Security Blanket ! Make it much harder to be insecure Architecture as a forcing function
  44. 44. Incoming Request Controller Application logic, doesn’t have to worry about headers at all. Outgoing Policy Adds all security headers by default. Can be configured with a list if necessary. Response Response has headers by default. It’s more work to get rid of them. Architecture as a forcing function
  45. 45. ! Guidelines, not rules ! Do your own research ! Security comes in layers Wrapping up
  46. 46. Thank You! @godfrzero @postmanclient

×