Building a secure BFF at Postman
- 1. Building a secure BFF Ankit Muchhala - Postman ankit_muchhala
- 3. Backend For Frontend • BFF is an API Gateway designed for a specific UI to interact with microservices. • Abstracts away implementation details from client. • Reduces network chatter and improves performance.
- 4. Security concerns? • Single point of failure and attack. • Public facing service. • Handles user input. • How to quantify these for an API?
- 5. Security Parameters Confidentiality Integrity Availability Only authorised people can access appropriate data. Data delivered by your service is not tampered with. Content is available to authorised users to on demand.
- 7. Service Server side code which contains your business logic
- 8. Validation • BFF should not perform all validations. • It should perform ecosystem checks - auth, validate header. • Business logic specific checks are deferred to downstream services.
- 9. Critical Path • Services called before request reaches the business logic. • Critical path length is an indicator of the amount of validation done on BFF. • Good to have a short critical path and fallbacks.
- 10. function hasAccess (user, owner) { } Principle of Least Privilege • User only has access to minimum resources that are necessary. • Always assume user does not have access by default. • Allow only for specific conditions. if (user.isAdmin) { return true; } if (user.id === owner.id) { return true; } return false;
- 11. Sample BFF
- 12. Architecture • Make it harder to be insecure. • Separate business logic from access control and validation. • Stack installation with predefined security setup using yeoman. security-hook orm-hook auth-hook
- 13. Vulnerable Dependencies • Use strict versions for dependencies and lockfiles. • Check vulnerable dependencies in CI pipeline. • Tools - nsp, npm audit, snyk. $ snyk test ✗ Medium severity vulnerability Description: ReDoS Introduced through: something@0.9.1 Resolution: ... ✗ Medium severity vulnerability Description: TOCTOU Introduced through: package@1.2.0 Resolution: ...
- 14. Enforcing Security • Security linting. • System tests to catch configuration issues. • E2E tests using Postman collections integrated into the CI pipeline.
- 15. E2E tests in Newman
- 17. Handling Internal Auth • Abstracting away internal server details from developer. • Prevents server auth leak in response or logs. • Allows for secret rotation without server side code changes. user: async function (req, res) { let user = await internal({ service: 'auth', path: '/users/current', query: { populate: true } }); return user.toJSON(); }
- 18. Request tagging • Associate each incoming request with a user associated token. • Each service can utilize this token to fetch user meta and apply validations.
- 19. IDOR • Exposing internal object references along with incorrect access control. • All user initiated actions must have verifications based on user tokens.
- 20. Logging • Scrub logs for sensitive information and user data. • Use heuristics to prevent accidental logging. • Trace logs originating from BFF to track potential PII movement.
- 21. Outbound Content security while communicating with the client.
- 22. HTTPS / HSTS • Choose the certificate based on your need and the level of user trust required - DV, OV, EV • Ensure 3rd party calls and redirections are over HTTPS. • Implement HSTS (+ preload) once you have verified everything is over HTTPS. RFC 2818, 6797
- 23. CSP • Reduces the harm caused by malicious code injection. • Start by using report-only mode to prevent side effects. • Not ideal to prevent data exfiltration - hrefs not covered. Content-Security-Policy: connect-src: 'self' script-src: 'none' img-src: * default-src: 'none' report-uri: 'https://...' RFC 7762
- 24. Other Headers • CORS: Who can access your resource. • X-XSS: Detect and prevent XSS in some browsers. • X-Frame-Options: Permit or deny displaying the website within an iframe. • HPKP: Allows HTTPS websites to resist impersonation. • SRI: Verify 3rd party assets • Refer OWASP Security Headers Project for more.
- 25. Caveats • The support for all the headers is dependent on client browser. • Cannot be solely relied on for securing your BFF. • Not a replacement for deliberate input validation and output formatting.
- 26. Platform Security considerations and processes for infrastructure.
- 27. Audits & Automation • What to audit? • Developer access • Setup configuration • Creation of new resources • We use collection runs to create new resources reliably. • Postman Monitors to perform periodic audits of our services.
- 29. Health Check • Verify critical config based on environments. • Prevent deployment if there is something obviously wrong. Ex. leaking private keys. • This is a safety net and not a testing mechanism.
- 30. SDLC Processes involved to ensure security
- 31. Security KPIs • Vulnerability categorization by CVSS scores. • Vulnerability regression. • Time to resolve - SLA. • External security reports - user identified, Hacker One, etc.
- 32. VAPT • Post-development step to assess the security of a software release. • Black box and white box testing of services. • Automation of security processes.
- 33. Outro
- 34. Revisiting Security Parameters Confidentiality Integrity Availability • Validation • PoLP • Log scrubbing • Request tagging • Access control (IDOR) • Content security (HTTPS, SRI, CSP, etc.) • Short critical path • Platform audits • Healthcheck
- 35. Key Takeaways • Security considerations while building a BFF / public API. • Building a secure API is a gradual process. • Security is a part of development process.
- 36. Thank you