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
{{ message }}
This repository has been archived by the owner on Sep 11, 2019. It is now read-only.
Hi there.
Currently using the Roslyn security guard extension for VS. We have a few Web Api projects, for whom, the controllers are not linked to a view, therefore the normal [ValidateAntiForgeryToken] would not have any effect. Your product correctly flags up those methods to be vulnerable when no such security tag is attached to the method.
We have created our own Anti-Forgery Token validation attribute for WebApi projects, but for obvious reasons this is not called [ValidateAntiForgeryToken] , as it would conflict with existing functionality.
As Roslyn Guard checks for that exact tag, our secure methods are still flagged up as insecure ( false positives ) and makes it a bit inconvenient when reviewing a very large project, to go on check every single warning ( beats the purpose of using the product in the first place, as we could just manually visit every [HttpPost] ) .
Was wondering if anything could be done about this ? ( could check for a tag containing the string AntiForgeryToken , rather than a strict lookup )
The text was updated successfully, but these errors were encountered:
Hi there.
Currently using the Roslyn security guard extension for VS. We have a few Web Api projects, for whom, the controllers are not linked to a view, therefore the normal [ValidateAntiForgeryToken] would not have any effect. Your product correctly flags up those methods to be vulnerable when no such security tag is attached to the method.
We have created our own Anti-Forgery Token validation attribute for WebApi projects, but for obvious reasons this is not called [ValidateAntiForgeryToken] , as it would conflict with existing functionality.
As Roslyn Guard checks for that exact tag, our secure methods are still flagged up as insecure ( false positives ) and makes it a bit inconvenient when reviewing a very large project, to go on check every single warning ( beats the purpose of using the product in the first place, as we could just manually visit every [HttpPost] ) .
Was wondering if anything could be done about this ? ( could check for a tag containing the string AntiForgeryToken , rather than a strict lookup )
The text was updated successfully, but these errors were encountered: