Ράδιο αμορε

Hi, I would like to have a demo session to review your product. I booked from your site some couple of days back and I am still yet to get a response

Thanks for explaining the concept in a simple way

Thank you ! I missed an interview yesterday because I couldn’t recall these latest OWASP API Vulnerabilities 😅

Great job 👌👍

how you created the animation ?

Am kinda amazed its 22 and still not enough resources on yt for api security.

Thanks! We make this attack info available only to signed customers at this time but we appreciate understanding that this info could help the broader community and are looking at more ways to share our API attack insights. We do have additional info here: salt.security/blog-authors/salt-labs

can you share the postman collection?? Please!🙏🙏

can you share the postman collection if possible..

Great presentation - just trying to get my head around how API flows might disclose business logic flaws in a TLS (1.2 or 1.3) session - I understand most state is kept at client side but still...

😂 ᴘʀᴏᴍᴏsᴍ

Appreciate the video.. interesting. I believe the title should of been API Attacks - Cloudflare WAF vs Salt Security since some WAFs are way more powerful, for example the AWAF by F5 is much more capable then the free version of cloudflare but thats my opinion only. Curious if there is somewhere I can download the Postman scripts you have so I can do some evaluation of our own. We recently purchased SALT Security (not implemented yet) and would like to do some of the same evaluations. Thanks again for the video

The below are my observations from this video.| 1) API is developed with consist of set of business functionalities. Each business functionality is described (insert/update/delete) operation or (viewing the single record operation) or (viewing list of records operation). 2) Each API should be privileged to access by User Groups. Each functional operation of API should also be authorized to access by user groups. The few list of attackers Vulnerabilities ---------------------------------------------------- 1) if user who does not have privileges and is trying to access the API their request API call should be blocked by API. 2) If attackers is trying to hijack user sessions and trying to access API , they API should reject those requests. 3) For each API call , the Session Authentication and API Operation authorization should be validated.. 4) If attackers are trying to modify/alter the data which was sent by user as part of API call, then API should validate and block those requests.

Great information. The foundations of cybersecurity are very rapidly changing. Would Salt Security's API protect small tax preparation offices that fully depend on external cloud-based services such as Intuit's ProConnect tax, Intuit Link for file sharing and Google Workspace office apps? OR Is Salt Security more directed at companies like Intuit itself to help Intuit secure its APIs. Another question: If we are using Google's AppSheet no-code system to create new API-based apps, are those apps automatically fully secured against all of the threats mentioned in your video? Should we / can we integrate Salt's API security into our AppSheet created programs for full spectrum API security? Can Salt's API security system even be integrated into these no-code, click-n-build app programs?

kzbin.info/www/bejne/fISTeaCdr7uWl6s A discussion and a high level overview of things.