Here is Coursera's official response: <a href="http://blog.coursera.org/post/96686805237/response-to-reported-vulnerability-in-instructor-access" rel="nofollow">http://blog.coursera.org/post/96686805237/response-to-report...</a>.<p>We have already implemented fixes and mitigation strategies for all of the vulnerabilities - including completely disabling type-ahead hinting for email address on our instructor interfaces (instructors must now enter the complete email address of a learner in order to manually enroll him or her in the instructor's course) and rate limiting and referrer header checking on APIs to slow down and stop enumeration attacks by third parties to discover learner enrollment status for courses.<p>Finally, we would like to thank Dr. Mayer for reporting these security problems and helping us make Coursera a more secure and privacy conscious platform for our learners.
Tech debt is like monetary debt -- you still have to pay it back, and quick. When it's security / API related debt, you have to pay it back even quicker, because if you don't, someone inevitably forecloses on your metaphorical house and repossesses your metaphorical car.
> I reported the issue to Coursera on Sunday, and I have not yet received a response. Possible remediation steps include rate limiting (again), referrer checking, and configuring APIs to always return the same HTTP status.<p>Wouldn't the 2nd issue (the cross-origin data leak) be better off solved by having a CSRF token instead?
Accepting a role in an organization, only to turn around and immediately publicly humiliate and embarass them (for no good reason[1]), is just about the biggest dick move one can make.<p>I hope this guy finds his 5 seconds in the limelight to be worth sacrificing his common decency to.<p>[1] Because they appear to be in the process of addressing the issues in a timely manner.
Hiding the IDs doesn't have to be a security feature at all. Maybe they just didn't want to publicly show how many students they've got, simply for marketing reasons?