If you feel that you have found a bug on our website or in your widget, before reporting it, please check:
- Browse our support page to see if similar problem was already reported. For instance broken images in the widget is not a bug, but a result of expired access token.
- If your widget behaves weirdly without any modifications on your end and you are using custom CSS for your widget, please check our blog to see if any updates were issued recently. Sometimes the HTML structure or class names changes in the widget. Blog post usually covers the changes and gives you the alternatives that you can use in your Custom CSS.
If you found a bug that is not mentioned on the support page nor it’s the fault of the Custom CSS and widget update, please report this bug via our Support form. Someone from our team will review your support ticket, investigate and take further actions to resolve the issue.
Reporting security issues
If you believe that you have found a security vulnerability on LightWidget, we encourage you to let us know as soon as possible – we take security seriously. Our team will investigate all reports and do our best to fix the problems.
You can report security vulnerabilities directly via our Support form. Before reporting it, please read carefully the entire document to ensure that the problem can be investigated as soon as possible and that it is not out of scope.
During your submission please provide us with the list of steps that reproduce the security issue and that are easily understood. We need to be able to reproduce the issue on our end. Your submission will be reviewed and validated by our team. Although we will try to reproduce the issue and fix the bug as soon as possible, it may take some time before you will get a response.
We also ask that you give us a reasonable time to investigate the reported issue and to fix the problem. We ask for responsible disclosure, not sharing any information with the public or with others. Please try to avoid privacy violations and disruptions to other users of our website as well as destroying the data.
Some of the security vulnerabilities might be excluded unless you can provide us with evidence of exploitability. The following examples are excluded:
- Clickjacking with no practical security impact
- Content spoofing
- Invalid or missing SPF/DKIM records
- Missing cookie flags on non-sensitive cookies
- Missing HTTP security headers
- Open redirects with low security impact
- Logout and other instances of low severity CSRF.
- Self-XSS unless it is exploitable via reflected, stored or DOM-based attack
- SSL/TLS best practices and recommendations
- Username or email enumeration on Login and Forgot password page error messages
- WordPress configuration recommendations or plugins recommendation for our main website
- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms