If you are planning to publish partner APIs for exposing your business services or data to your partners and customers, you may want to consider following top 7 secured best practices to ensure application level security:
[adsenseyu2]
- Access-token based Authentication: Have your partners’ applications authenticate itself (and its users) using access-tokens rather than actual passwords. This is because access-tokens may be easily time-boxed and can be enforced to be renewed at the regular time-intervals. And the theft of access token can not really compromise the actual users’ password with the parent application. In this relation, you may consider using OAuth based authentication technique. In addition to usage of access-token for authentication, encourage partners to use secured encrypted keystores for storing these tokens. The idea is to not encourage partner applications, in any way, to store actual password of the users and exchange passwords in transit. This shall not only ensure strong authentication but also avoid password theft from data at rest (in database) or in transit (when exchanged over internet). These are security threats listed as top 10 in OWASP, one being authentication and other being sensitive data exposure.
- Input Data Validation: Sanitize all data coming from partners’ applications. Encourage your partners to also adopt the data sanitization techniques. In this regard, it may be good idea to create a white-list of allowed inputs which can pass through data santization process. It can surely mitigate risks posed by cross-site scripting (XSS) and SQL injection attacks. These are top two security threats identified by OWASP. You may want to consider using OWASP ESAPI libraries to filter inputs consisting of JavaScript <script> tags, HTML tags if required, characters used for SQL injection etc. For details, you may check out XSS cheatsheet wto understand inputs that can lead to XSS attacks. For avoiding SQL injection attacks, you may consider two primary techniques such as escaping before creating your SQL statement and using parameterized input to create statements.
- Escape Output Message: Escape output message such as SQL queries, HTML, JSON, XML messages etc. This is again to mitigate risks from XSS security threat. In this relation, the thumb rule you may want to follow is “Filter Input, Escape Output” also termed as FIEO.
- Accept Every Requests with a Token: Encourage your partner applications to send a unique trusted token (generated by you and stored by partner applications) with every request. This is to ensure that all requests coming to your application are coming from trusted partner applications and no one else. This is to mitigate the risk posed the one of OWASP top 10 security threat, termed as Cross-Site Request Forgery (CSRF).
- SSL-based Transport: Make sure you accept all the requests from partner applications over SSL. This would surely avoid data theft in transit and mitigate threats from one of the OWASP top 10 security threats, termed as Sensitive Data Exposure.
- Minimal Exception/Error Message: Avoid exposing debugging messages which ends up giving sensitive information about application, database, business rules etc. This is to mitigate risk that could arise due to one of the OWASP top 10 security threats, termed as Security Misconfiguration.
- Security Reporting: Encourage partners and customers to send reports on suspicious exception/error messages or any suspicious activity. This would help you to improve on security measures in a sustained manner and avoid hacking attacks.
I am sure there could be more to above list. Please feel free to comment/suggest to the above list.
Latest posts by Ajitesh Kumar (see all)
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
I found it very helpful. However the differences are not too understandable for me