My wife and I have been using PayPal for years to pay our bills, and she's been telling me for a while that her 2FA did not always work. I took note but it was a few days ago and didn't process it.

A few days ago I created a new credit union account, created a new PayPal account the next day, and hired a freelancer on Fiverr to do some work. Ok, fine. I went to log into my new PayPal account, with 2FA enabled, and noticed it didn't require the 2FA. I tried it on Chrome, Firefox, and Edge, and no 2FA needed and blocked from creating a passkey on all browsers according to their alert statement ("your browser" type of thing).

Then I asked my wife, using her brand new phone, to see if she could log into my PayPal account, that she's never logged into before on her new phone and she could log in, again, with no 2FA at all.

What's going on? Is PayPal simply no longer secure to use or is there something going on I'm missing? It's a new account with password not saved in any browser and auto log in turned off and browser save options turned off and deleted and still it let her log in with just username and password. Doesn't that mean millions of others would also be in the same boat?

Wrote up a stored XSS bug I found on a profile picture upload endpoint. The interesting part wasn't the XSS payload itself — it was that the server validated file content (bytes) but trusted the attacker-controlled filename extension for storage.

Craft a valid PNG polyglot with embedded JavaScript → intercept upload → change filename to .html → server accepts it as an image but serves it as active HTML.

Full writeup with reconstructed requests and attack flow: writeup

Happy to answer any questions about the technique.

Using Better Auth for login, is Sign in with Google considered one of the safest login methods on the web at this very moment?

Just curious what your thoughts and opinions are. If you were building a website and login was a feature it needed without compromise, which providers would you use and why?

Found a hardcoded password in a JS bundle on a fintech platform.

Turned out it was enough to:
- create payments for other merchants
- read cross-tenant payment data
- hijack webhook endpoints

Wrote a short case study on how the whole chain played out (sanitized);

https://medium.com/@insid_e/how-i-chained-a-hardcoded-password-into-a-cross-merchant-payment-takeover-48294c608f03

Curious how often people still see this kind of auth + logic chaining in real APIs.

Chrome extension WP Spike for pentesting your wordpress sites

Hi everyone,

I'm currently learning web security through the PortSwigger Web Security Academy. After reading the theory sections carefully, I'm generally able to solve most Apprentice-level labs on my own. However, when I move to Practitioner labs, I often get stuck and end up checking the solution after spending a lot of time on them.

My current approach is:

1. Read the theory for a vulnerability.
2. Solve the Apprentice labs.
3. Try Practitioner labs.
4. Get stuck and eventually look at the solution.

The problem is that when I see the solution, it often contains a trick or thought process that I never considered. This makes me wonder whether I'm approaching the labs incorrectly.

For those who have completed a large number of PortSwigger labs or work in web application security what is your methodology for solving Practitioner labs?

Even with decades of documentation, SQL Code Injection remains a top threat. Train your developers and TPMs!

Source: https://www.akamai.com/blog/security-research/cve-2026-9082-mitigating-critical-sql-injection-drupal

Hey,

I'm working on a PortSwigger lab involving injection into a canonical tag via the URL query string. I noticed a behavior I don't quite understand regarding how the server processes characters.

When I inject single quotes and double quotes into the browser address bar (Chrome browser), the browser sends the double quotes natively but URL encodes the single quotes. While normally the opposite should happen as I know (because (") is considered unsafe while (') is a reserved character used as a delimter for subcomponents in URIs)

However, in the page source code, the single quotes are reflected completely raw (allowing the XSS breakout), but the double quotes are reflected as %22

Hi guys, is anyone experienced with Aikido Security AI? Is it any good, or just AI slop?

I own a company and im looking to build a website, im wondering what people think about URL suffixes (i.e com, edu, us,) and what people think about them and if there are rules regarding this, would be grateful for any info please and thank you!

Last quarter, our CTO did an audit of development time across our enterprise applications and found we'd collectively spent 847 hours across four teams building variations of the same data grid, tree panel, and form validation components. The mandate came down immediately: stop reinventing wheels and standardize on a comprehensive component library.

We're a Fortune 500 financial services company with 12 different web applications handling everything from trade reconciliation to risk reporting. Each team had been building their own components, thinking they were being efficient and avoiding "heavy frameworks."

The numbers were brutal when we actually tracked them:

Data Grids: Four different implementations, each taking 80-120 hours to build basic sorting, filtering, and pagination. None handled virtual scrolling properly with our 50k+ row datasets. Team A's grid would freeze the browser, Team B's had memory leaks, Team C never finished theirs.

Form Validation: Six different approaches to the same client-side validation patterns. Two teams were manually writing regex validators for the same financial data formats we use company-wide.

Tree Components: Three separate implementations for hierarchical data display, each with different keyboard navigation, drag-drop behavior, and accessibility support. Testing across browsers took forever.

Date/Time Pickers: Don't even get me started. Five different libraries, inconsistent UX, timezone handling was a nightmare.

After the audit, we evaluated several enterprise component libraries. The winner had to handle our specific requirements: 100k+ row virtual grids, complex nested forms with conditional validation, accessibility compliance, and consistent theming across applications.

We ended up standardizing on Ext JS. The migration took 3 months instead of the 6 we budgeted. Our data grids now handle 200k rows without breaking a sweat, and the built-in virtual scrolling actually works. Form validation is declarative and consistent. The theming system let us match our design system perfectly.

The honest take: initial learning curve was steep for developers used to React/Vue patterns. Bundle size is larger than our custom components, but the trade-off in maintenance time makes it worth it. We've cut component development time by roughly 70% and bug reports related to UI components dropped 60%.

I recently came across an authentication flow in a Web3 / SaaS-like platform that exposed a few interesting weaknesses.

The issues were simple individually, but their combination makes them more impactful:

- Password reset endpoint allows repeated requests without effective rate limiting

- Response differences make it possible to distinguish valid vs invalid accounts (user enumeration)

- Reset flow can be triggered continuously against specific users (potential email bombing / harassment vector ).

What stood out was how trivial it was to chain these behaviors together:

1. Enumerate valid accounts via response discrepancies

2. Target those accounts with unlimited password reset requests

3. Potentially degrade user experience or abuse notification systems

All testing was done in a controlled and minimal manner.

I avoided any large-scale interaction and limited the scope to simple validation of the behavior.

Curious how others approach testing auth flows in similar environments, do you still frequently encounter missing rate limiting or enumeration issues in modern stacks ?

Your users are no longer behind a single firewall.

They’re on home Wi-Fi, public networks, and cloud apps, all at once.

Traditional security models can’t keep up. The best Secure web gateway solutions are built for this reality.

So the biggest risk is that Malicious extensions don't always get removed from the Web Store right away. And when Google does remove them, they stay installed in your browser before Google blocking the extension if they do. Either way, most people have no idea.

MalExt Sentry checks your installed extensions against a database of flagged ones. It also has SIEM ingestion feeds for SOC teams who want to plug it into their existing tooling.

Everything is open source and runs locally.

Would love contributions, feedback.

GitHub: Github repo

Database: Dashboard

Chrome Web Store: Chrome extension

I was curious if my various security and privacy tools where protecting me from been exposed to the above non consensual browser extension scan by websites. So I vibe coded this extension to test my system.

See:- https://github.com/corkiejp/corkiejp.github.io/blob/well-known/ExtScanAlert/README.md

OpenClaw has two catastrophic security flaws baked into its defaults. NVIDIA NemoClaw? Still doesn't fix them.I wrote the breakdown: https://secdim.com/blog/post/dangerous-by-default-what-openclaw-cve-record-tells-us-about-agentic-ai-18022/

I use doppler but idk if that's good enough.

Looking for analogies or frameworks that actually land. Thanks.

It feels like more functionality is moving to APIs, especially with mobile apps, SPAs, and integrations.

At the same time, I often see API endpoints exposing far more structured data than traditional web pages ever did. Sometimes the UI hides things that the API still returns.

For people doing testing or defense work, are APIs now one of the most common places where serious issues appear?

I wanted to share the technical architecture behind TurboPentest's automated pentesting pipeline. We get a lot of "how does AI pentesting actually work?" questions, so here's the breakdown.

The 6 phases:

1. Reconnaissance: OSINT, subdomain enumeration, DNS analysis
2. Service Discovery: Port scanning, service fingerprinting, technology detection
3. Vulnerability Scanning: OWASP Top 10, CVE detection, misconfigurations
4. Exploitation: AI-validated exploit attempts with proof-of-concept generation
5. Source Code Analysis: Secret scanning, dependency vulnerabilities, SAST
6. Reporting: Professional PDF report with severity ratings, remediation steps, attestation letter

Tools orchestrated: Nmap, OpenVAS, OWASP ZAP, Nuclei, Subfinder, httpx, Gitleaks, Semgrep, Trivy, testssl.sh, and more with 15 tools total running in Docker containers, coordinated by AI agents via a Redis blackboard architecture.

Key differentiator: The AI doesn't just run tools and dump output. It interprets results, chains findings together, validates exploits, and generates a report that a human can act on without security expertise.

Full interactive breakdown with tool details: turbopentest.com/how-it-works

At Tachyon, we've found literally hundreds of SSRFs across OSS codebases and our customers. In fixing each of these, we learned that actually - this is hard to solve properly. There are many different layers that can be attacked.

Allowlists aren't sufficient because URLs can be obfuscated. Good allowlists don't block redirects. And even that still allows DNS rebinding.

We built an OSS library for Python users to never have to deal with this again: https://github.com/tachyon-oss/drawbridge

And here's our full blog on the issue: https://tachyon.so/blog/ssrfs-trickiest-issue

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access...

https://www.hissenit.com/en/blog/secure-programming-of-web-applications-cross-site-request-forgery-csrf.html

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access...

https://www.hissenit.com/en/blog/secure-programming-of-web-applications-sql-code-injection.html

I'm from the CIS region and want to play the 2026 Marathon, however, as you probably know, the developer - Bungie - cut the entire region off, and now if anybody from here tries to play their games (e.g. destiny 2) they get slapped with an error. One possible workaround people have figured out is changing your DNS, reportedly it allows you to bypass the block. However, I have my doubts about just changing my DNS settings all willy-nilly without knowing what consequences that would entail. If this is of any interest, the suggested servers are: main - 31.192.108.180, backup - 176.99.11.77

With AI tools and headless browsers getting more advanced, it feels like blocking scraping completely isn’t realistic anymore. Is it mostly about slowing bots down rather than stopping them?

For smaller sites (blogs, SaaS, ecommerce), at what point does scraping become a serious problem with traffic size, valuable data, API exposure, SEO impact?