Is your website Secure!
inspect.new
inspect.new
Additionally it seems to have issues with random sites given as parameter, only working with the displayed examples.
we used to avoid that, and making the input field very sanitised about the input
we used to avoid that, and making the input field very sanitised about the input
Permissions-Policy is an extension of Content-Security-Policy. If you embed third party contents in your page, you will absolutely want a CSP and a permissions-policy. If you made the site yourself, if what's being served up is all yours and no third party code, you have no need for this header. Because you know you won't ask for permissions you don't need.
This service has no idea whether you're a 3rd-party-embedding site or not, and can't know because the 3rd-party data could appear directly in the HTML (e.g. blog comments). So they can't say you must have this header. It's a false positive to say you need it, and it's needless box-ticking to add one if you don't need one.
Ironically, my own site would pass this because for a fleeting time in the past, Google were trying to force new ad-tech on everyone, and the only way they offered to opt out (it was not opt-in as it should be) was for site owners to write Permissions-Policy:interest-cohort=() -- see https://amifloced.org/
Last week we got a pentest done on our apps. This week we got some high-prio tickets on our board because they found major security violations!!! Our app, which uses an API, used a dangerous permission! "android.permission.INTERNET"
How they can report this with a straight face, I don't know. Makes me want to go in the security business though, if that is the level of competence I'm absolutely positive that I could do that job and earn a lot more than a generic app developer.
The app in question: a wrapper of a PWA ticket purchase webapp which saves no payment info.
Being able to run on rooted device was determined as severe category.
if anyone wants to try it out
Most sites I sent to it came back with plenty of false positives, mainly because htaccess rewrites resolve the URIs as query string IDs and returned empty pages with "Sorry, but the information you're looking for doesn't exist..."
Either it complains that my domain isn't valid in the input, or it redirects to the landing page if I add my domain to the URL.
we used to avoid that, and making the input field very sanitised about the input
Additionally, I get "Connection error, please refresh the page." for a website that clearly is accessible.
https://blog.postman.com/what-are-http-headers/
https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_...
https://developer.mozilla.org/en-US/observatory (formerly https://observatory.mozilla.org/)
Or Security Headers?
Or VENOM?
https://github.com/oshp/oshp-validator
Applaud the effort, these are things that more devs should be aware of when building websites...
Hey some specific feedback on this tool... On mobile, it has a lot of "view port wobble" and the input fields aren't keyed right, it's just using a straight text input field so you don't get any ".com" buttons as you type.
The forms use light gray text on a dark gray background -- that isn't at all aligned with WCAG standards. https://i.imgur.com/BNCC5Dx.png
And it really needs to work on what it thinks is a valid URL. https://i.imgur.com/N1ctafd.png
Small UX stuff like that annoy me more than if a page has a privacy policy setup correctly. (=
Lastly, Permissions Policy... good concept, but still in "DRAFT" so not quite something you can ding users for not adopting just yet.
https://www.w3.org/TR/permissions-policy/
https://caniuse.com/permissions-policy
If you want to play around with it, here's a good tool to generate examples. https://www.permissionspolicy.com/
Oh lastly lastly, there are some really easy tools out there for helping to create a Content Security Policy, these really speed up the process. (Just make sure you disable your ad-blockers before running.)
thanks for the suggestions and will be more features comes out to be better to enhance the experience and the knowledge for devs about some other security manners
EDIT: seems like the form submission is doing a POST to https://inspect.new, which returns a 500 error.
Even large corporations rely largely on buying reports, and in turn buying products to fix the results of those reports as their primary security strategy.
Also, auditors use tools like this or have their tools to get reports telling them they are 100% secure.
No one should ever assume 100% security, even when the odds suggest otherwise. Maybe you are right.
SOC2/ISO27001 audits are just "are you living up to the processes you defined yourself for SOC2 compliance", not "are you secure". It is dealt with by whatever Compliance unit the company has and only serves to avoid legal issues, and has nothing to do with whoever runs IT security.
Security audits is usually quite laughable, and work tends to be initiated by security vendors who happen to have a scan that gives some "very bad" result which they just so happen to have a silver bullet product to fix. Then the company uses that scan until the next company comes along...
Few companies take security seriously, designing things for security rather than just buying whatever bandaids they see in the store.